page fault in propagate_priority
John Baldwin
jhb at FreeBSD.org
Wed Oct 29 09:29:49 PST 2003
On 28-Oct-2003 Dan Nelson wrote:
> In the last episode (Oct 28), John Baldwin said:
>> On 28-Oct-2003 Dan Nelson wrote:
>> > I've gotten the following panic twice in the last few days. I'm
>> > pretty sure truss has something to do with it, since I just started
>> > trussing something when it paniced. No crashdumps unfortunately,
>> > and the system locks up hard so I have to reset it.
>> >
>> > The fault address is 0x24 so it looks like a null pointer
>> > dereference of some sort. I've added asserts to propagate_priority
>> > any place a pointer to a structure is dereferenced, so if it
>> > happens again I should have the line number at least.
>> >
>> > panic1 was on an Oct 15 kernel, panic2 was on an Oct 27 kernel.
>>
>> It might help some if you could use gdb -k on your kernel.debug and
>> do 'l *propagate_priority+0x66' to see where it is dying.
>
> Yes, definitely :)
>
> (gdb) l *propagate_priority+0x66
> 0xc0575b36 is in propagate_priority (../../../kern/kern_mutex.c:178).
> 171 m = td->td_blocked;
> 172 MPASS(m != NULL);
> 173
> 174 /*
> 175 * Check if the thread needs to be moved up on
> 176 * the blocked chain
> 177 */
> 178 if (td == TAILQ_FIRST(&m->mtx_blocked)) {
> 179 continue;
> 180 }
> 181
> 182 td1 = TAILQ_PREV(td, threadqueue, td_lockq);
>
> So I guess m was NULL here. If I had INVARIANTS enabled, it would have
> paniced at line 172. Time to re-enable those kernel debug options :)
Well, mtx_blocked might be null. You don't happen to have ADAPTIVE_MUTEXES
on do you?
--
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
More information about the freebsd-current
mailing list