Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /usr/src/sys/kern/kern_exit.c:912

Kostik Belousov <kostikbel_at_gmail.com> wrote:

> On Sun, Apr 10, 2011 at 03:37:59PM +0200, Fabian Keil wrote:
> > The following panic seems to be reliably reproducible with sources
> > from yesterday (and today) by running claws-mail in X, switching to
> > the console and trying to attach gdb to it with 'gdb -p $(pgrep claws-mail)'.
> > 
> > gdb somehow fails to attach, and after leaving gdb the panic occurs.

> > fk_at_r500 /usr/crash $kgdb /boot/kernel/kernel vmcore.0 
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "amd64-marcel-freebsd"...
> > 
> > Unread portion of the kernel message buffer:
> > panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock _at_ /usr/src/sys/kern/kern_exit.c:912
> > 
> > cpuid = 0
> > KDB: enter: panic
> > panic: from debugger
> > cpuid = 0
> > Uptime: 3m48s
> > Physical memory: 1974 MB
> > Dumping 331 MB: 316 300 284 268 252 236 220 204 188 172 156 140 124 108 92 76 60 44 28 12
> > 
> > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done.
> > done.
> > [...]
> > Loaded symbols for /boot/kernel/drm.ko
> > #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:250
> > 250             if (textdump_pending)
> > (kgdb) where
> > #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:250

> > #11 0xffffffff80531a60 in panic (fmt=Variable "fmt" is not available.
> > ) at /usr/src/sys/kern/kern_shutdown.c:574
> > #12 0xffffffff805222f9 in _mtx_lock_sleep (m=Variable "m" is not available.
> > ) at /usr/src/sys/kern/kern_mutex.c:341
> > #13 0xffffffff805223a5 in _mtx_lock_flags (m=Variable "m" is not available.
> > ) at /usr/src/sys/kern/kern_mutex.c:203
> > #14 0xffffffff80503789 in proc_reparent (child=0xfffffe001290a000, parent=0xfffffe0012e48900) at /usr/src/sys/kern/kern_exit.c:912
> > #15 0xffffffff80503ed8 in kern_wait (td=0xffffff8000017adc, pid=Variable "pid" is not available.
> > ) at /usr/src/sys/kern/kern_exit.c:708
> > #16 0xffffffff805043e5 in wait4 (td=Variable "td" is not available.
> > ) at /usr/src/sys/kern/kern_exit.c:653
> > #17 0xffffffff805751ab in syscallenter (td=0xfffffe00028838c0, sa=0xffffff8000017bb0) at /usr/src/sys/kern/subr_trap.c:344
> > #18 0xffffffff807ce8bc in syscall (frame=0xffffff8000017c50) at /usr/src/sys/amd64/amd64/trap.c:910
> > #19 0xffffffff807b95cd in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:384
> > #20 0x000000000040cb8c in ?? ()
> > Previous frame inner to this frame (corrupt stack?)
> > (kgdb) f 14
> > #14 0xffffffff80503789 in proc_reparent (child=0xfffffe001290a000, parent=0xfffffe0012e48900) at /usr/src/sys/kern/kern_exit.c:912
> > 912             PROC_LOCK(parent);
 
> > I cannot reproduce the panic with a kernel from 2011-03-12
> > which I haven't deleted yet, but didn't try to bisect it further.
 
> > In related news, the kernel from yesterday also seems to panic/hang/whatever
> > when claws-mail segfaults due to an invalid memory access, but as I was running
> > X, I got no core dumps for those problems either.
> 
> For the first problem, try patch at the end.

It solves the problem.

> Regarding the 'panic/hang/whatever', I cannot reproduce it with a program
> that specifically access unmapped memory. You would need to catch core
> dump and provide the backtrace.

With your patch, I can no longer reproduce the second issue either.
Maybe the segfault itself wasn't the problem and claws-mail's
forked crash handler simply triggered the same panic.

Thanks a lot.

Fabian