Re: page fault in propagate_priority

In the last episode (Oct 29), John Baldwin said:
> On 28-Oct-2003 Dan Nelson wrote:
> > In the last episode (Oct 28), John Baldwin said:
> >> On 28-Oct-2003 Dan Nelson wrote:
> >> > 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?

Nope, don't have that set.  I still think m was null, since the fault
was at 0x24, and gdb says that mtx_blocked is 24 bytes into struct mtx. 
If mtx_blocked were null, you'd get a fault on 0x0 (since tqh_first is
the first element of mtx_blocked):

(gdb) p &((struct mtx *)0)->mtx_blocked
$1 = (struct {...} *) 0x24

-- 
	Dan Nelson
	dnelson_at_allantgroup.com