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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/QM0JLb2yJWMd3dtFlJb+upg Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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-m= ail)'. > >=20 > > gdb somehow fails to attach, and after leaving gdb the panic occurs. > > fk@r500 /usr/crash $kgdb /boot/kernel/kernel vmcore.0=20 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and yo= u are > > welcome to change it and/or distribute copies of it under certain condi= tions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > > This GDB was configured as "amd64-marcel-freebsd"... > >=20 > > 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 > >=20 > > cpuid =3D 0 > > KDB: enter: panic > > panic: from debugger > > cpuid =3D 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 > >=20 > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/k= ernel/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=3DVariable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:574 > > #12 0xffffffff805222f9 in _mtx_lock_sleep (m=3DVariable "m" is not avai= lable. > > ) at /usr/src/sys/kern/kern_mutex.c:341 > > #13 0xffffffff805223a5 in _mtx_lock_flags (m=3DVariable "m" is not avai= lable. > > ) at /usr/src/sys/kern/kern_mutex.c:203 > > #14 0xffffffff80503789 in proc_reparent (child=3D0xfffffe001290a000, pa= rent=3D0xfffffe0012e48900) at /usr/src/sys/kern/kern_exit.c:912 > > #15 0xffffffff80503ed8 in kern_wait (td=3D0xffffff8000017adc, pid=3DVar= iable "pid" is not available. > > ) at /usr/src/sys/kern/kern_exit.c:708 > > #16 0xffffffff805043e5 in wait4 (td=3DVariable "td" is not available. > > ) at /usr/src/sys/kern/kern_exit.c:653 > > #17 0xffffffff805751ab in syscallenter (td=3D0xfffffe00028838c0, sa=3D0= xffffff8000017bb0) at /usr/src/sys/kern/subr_trap.c:344 > > #18 0xffffffff807ce8bc in syscall (frame=3D0xffffff8000017c50) 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=3D0xfffffe001290a000, pa= rent=3D0xfffffe0012e48900) at /usr/src/sys/kern/kern_exit.c:912 > > 912 PROC_LOCK(parent); =20 > > 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. =20 > > In related news, the kernel from yesterday also seems to panic/hang/wha= tever > > 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. >=20 > 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 --Sig_/QM0JLb2yJWMd3dtFlJb+upg Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk2h3I4ACgkQBYqIVf93VJ3OAwCbBTCs/Khmm/SkHAn7dFYHQZaI F1AAoMeTEjxXPfEYdyZcif78+5beq3dx =rrU+ -----END PGP SIGNATURE----- --Sig_/QM0JLb2yJWMd3dtFlJb+upg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110410183623.29b3671e>