Date: Tue, 21 Jul 2009 11:14:47 -0400 From: John Baldwin <jhb@freebsd.org> To: Kamigishi Rei <spambox@haruhiism.net> Cc: Lawrence Stewart <lstewart@freebsd.org>, freebsd-current@freebsd.org Subject: Re: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal Message-ID: <200907211114.47691.jhb@freebsd.org> In-Reply-To: <4A65D1CD.40006@haruhiism.net> References: <4A659F98.2060007@haruhiism.net> <200907211027.06589.jhb@freebsd.org> <4A65D1CD.40006@haruhiism.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907211114.47691.jhb>