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 [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"