Date: Sun, 10 Apr 2011 18:36:23 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: Kostik Belousov <kostikbel@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /usr/src/sys/kern/kern_exit.c:912 Message-ID: <20110410183623.29b3671e@fabiankeil.de> In-Reply-To: <20110410151847.GT78089@deviant.kiev.zoral.com.ua> References: <20110410153759.025aa4e2@fabiankeil.de> <20110410151847.GT78089@deviant.kiev.zoral.com.ua>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Kostik Belousov <kostikbel@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@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 @ /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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk2h3I4ACgkQBYqIVf93VJ3OAwCbBTCs/Khmm/SkHAn7dFYHQZaI F1AAoMeTEjxXPfEYdyZcif78+5beq3dx =rrU+ -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110410183623.29b3671e>