Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sat, 22 Jul 2023 21:52:40 +0900
> From: PHO <pho%cielonegro.org@localhost>
> 
> >>     cv_destroy(&cv); // <-- Panics!
> >>
> >> It seldom panics on KASSERT(!cv_has_waiters(cv)) in cv_destroy() but not
> >> always. The panic seems to happen when cv_timedwait_sig() exits due to
> >> the timeout expiring before it gets signaled.
> > 
> > Confused by `seldom panics on ... but not always' -- was that supposed
> > to be `often panics on ... but not always', or is there a more
> > frequent panic than KASSERT(!cv_has_waiters(cv))?
> 
> I meant it didn't panic for most cases as if nothing wrong happened, but 
> it occasionally panicked due to KASSERT(!cv_has_waiters(cv)). Sorry for 
> my bad English.

OK, thanks!  No worries, just wasn't sure what you meant.  I might
phrase that as: `It sometimes panics on KASSERT(!cv_has_waiters(cv))
in cv_destroy(), but it doesn't always panic.' or `I sometimes see
KASSERT(!cv_has_waiters(cv)) panics.'

> > What exactly is the panic you see and the evidence when you see it?
> > Stack trace, gdb print cb in crash dump?
> 
> Wait, can we use gdb for examining the kernel dump? I thought gdb 
> couldn't read it. Here's the stacktrace found in /var/log/message:

Yep, you can use gdb to examine a crash dump:

$ gdb ./netbsd.gdb
(gdb) target kvm netbsd.123.core

You can even do this to poke around in the live kernel you're running!

# gdb ./netbsd.gdb
(gdb) target kvm /dev/mem

(Not at elevated securelevel, of course.)