Re: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal

On Tuesday 21 July 2009 10:33:49 am Kamigishi Rei wrote:
> John Baldwin wrote:
> > Can you print out 'owner' as well?  You won't get a panic until you actually 
> > dereference 'owner' to get 'owner->td_state' even though gdb will show this 
> > as the faulting line (gdb can sometimes get confused by compiler 
> > optimization).  You are seeing these values because mtx_lock was changed (due 
> > to either a mtx_unlock() or a mtx_init()) while you were spinning.   That 
> > value of v is not what I have typically seen in these panics.  Do you also 
> > have the original fatal kernel trap messages?
> >   
> Why does v change to a non-kernel address then? From what I see, it 
> should never get assigned a value that's not MTX_UNOWNED or 
> 0xfff......(address,flags). However, I can reproduce this trap in all 
> revisions starting with 195146 up to 195484 (and probably more, didn't 
> check yet; at 1956xx these traps stop occurring).

v didn't change, it was always the busted value.  Somehow mtx_lock was
corrupted to the value 0x14ee000 perhaps due to a buffer overflow bug or
something else.

-- 
John Baldwin