Fatal trap 12: page fault while in kernel mode (subr_turnstile.c) w/ trace

[John Baldwin]

On 08-Dec-2003 Robin Breathe wrote:
> John Baldwin wrote:
>> On 08-Dec-2003 Robin Breathe wrote:
>>>I've been experiencing the following repeatable panic on recent 
>>>-CURRENT. This one is against RELENG_5_2, as of around 18:00 U‎T today. 
>>>Until now I've not been able to get a dump, but thankfully one's finally 
>>>come :)
>> 
>> If you can reproduce the panic with INVARIANTS, it would be very useful
>> to know which, if any, assertions it trips.
> 
> Here's the output from DDB with INVARIANTS enabled, does it contain what 
> you need?
> 
> I think I spotted the error in my ways on failing to use previous forced 
> dumps (it won't dump itself without my doing a 'call doadump' manually), 
> so I have both DDB and GDB output.

Oof, you seem to have possibly hit a corrupted thread object.

> (kgdb) l *0xc0537aa6
> 0xc0537aa6 is in turnstile_wait (/usr/src/sys/kern/subr_turnstile.c:439).
> 434             td = curthread;
> 435             tc = TC_LOOKUP(lock);
> 436             mtx_assert(&tc->tc_lock, MA_OWNED);
> 437             MPASS(td->td_turnstile != NULL);
> 438             MPASS(owner != NULL);
> 439             MPASS(owner->td_proc->p_magic == P_MAGIC);
> 440
> 441             /* If the passed in turnstile is NULL, use this thread's 
> turnstile. */
> 442             if (ts == NULL) {
> 443                     ts = td->td_turnstile;
> (kgdb)

owner is not NULL, but it blew up trying to read owner->td_proc.
Hmm, actually then, I think the owner pointer is bad.  There was
a while after one of the KSE commits when people would get panics
with a thread whose td_proc was NULL, but I don't know if that bug
was ever figured out or fixed.  For owner to be wrong though,
mtx_lock in the relevant mutex must have been corrupted somehow.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/