Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: trap leads to lockdebug panic

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.


Home | Main Index | Thread Index | Old Index