> Date: Sat, 22 Jul 2023 21:52:40 +0900 > From: PHO <p...@cielonegro.org> > > >> 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.)