page fault in propagate_priority
Dan Nelson
dnelson at allantgroup.com
Tue Oct 28 15:48:33 PST 2003
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
More information about the freebsd-current
mailing list