[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: trap leads to lockdebug panic
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!
Main Index |
Thread Index |