Re: page fault in propagate_priority

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/