page fault panic tracked down (selwakeuppri())
truckman at FreeBSD.org
Tue Jan 6 11:42:43 PST 2004
On 6 Jan, Stefan Ehmann wrote:
> On Tue, 2004-01-06 at 03:06, Don Lewis wrote:
>> The parameters passed to feed_vchan_16() might be bad in such a way that
>> the KASSERT is happy, but the heap still gets trashed.
>> If you can't get the KASSERT failure without this code being in a module
>> (or get gdb to debug the module), it might be interesting to change this
>> KASSERT into an "if" test that prints the parameters and anything else
>> of interest and then calls panic().
> As a workaround I just built the sound modules with COPTS=-g and
> installed them.
> Unfortunately I haven't been able to reproduce the previous panic in the
> modules again. I hope I can restore the exact configuration to get the
> "bad bufsize" panic - this time with more debug info.
> This time I got one more page fault panic and then this - looks even
> more random to me
> panic: Most recently used by none
> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
> #1 0xc04e5178 in boot (howto=256) at
> #2 0xc04e5507 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
> #3 0xc0632077 in mtrash_ctor (mem=0xc37dcc00, size=0, arg=0x0)
> at /usr/src/sys/vm/uma_dbg.c:137
Looks like the heap got trashed again, but this time the damage was
first detected on the free list. Judging by the "none", I suspect that
the memory was overwritten by 0's, which seems to be the typical damage.
More information about the freebsd-current