Re: trap leads to lockdebug panic

[Sverre Froyen <sverre%viewmark.com@localhost>]

On Friday 21 November 2008, Andrew Doran wrote:
> 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.

Right.  Thanks for the explanation!

Sverre