Re: trap leads to lockdebug panic

[Andrew Doran <ad%netbsd.org@localhost>]

On Fri, Nov 21, 2008 at 10:36:30AM -0700, Sverre Froyen wrote:

> This is just an FYI.
> 
> While investigating the (now fixed) tun deadlock, I ran into the following 
> panic with a LOCKDEBUG kernel while rebooting a crashed system:
> 
> Mutex error: lockdebug_barrier: spin lock held
> 
> with the backtrace:
> 
> panic
> lockdebug_abort1
> rw_enter
> vm_map_lock_read
> uvm_fault_internal
> trap
> free
> wapbl_replay_start
> ffs_wapbl_replay_start
> ffs_mountfs
> ffs_mount
> 
> The trap was the result of bad call to free, which has since been fixed.  
> What 
> strikes me as strange, however, is the trace after the trap -- eventually 
> leading to a lockdebug panic.  Since the trap itself presumably is fatal, the 
> rest may be irrelevant.  On the other hand, if anyone finds it interesting, 
> here it is.

malloc_lock is held hence you get the lockdebug panic while handling the
trap. It's a bit of a pain but nobody has been interested in improving the
behaviour because it happens when you have both an existing kernel bug and
the LOCKDEBUG option: the output is confusing but it's possible to figure
out what has happened.

Andrew