Re: page fault in propagate_priority

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 :)

-- 
	Dan Nelson
	dnelson_at_allantgroup.com