Date: Tue, 28 Oct 2003 17:48:29 -0600 From: Dan Nelson <dnelson@allantgroup.com> To: John Baldwin <jhb@freebsd.org> Cc: current@freebsd.org Subject: Re: page fault in propagate_priority Message-ID: <20031028234825.GB2284@dan.emsphone.com> In-Reply-To: <XFMail.20031028181207.jhb@FreeBSD.org> References: <20031028224604.GA2284@dan.emsphone.com> <XFMail.20031028181207.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031028234825.GB2284>