page fault in propagate_priority
Dan Nelson
dnelson at allantgroup.com
Wed Oct 29 09:49:37 PST 2003
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
More information about the freebsd-current
mailing list