Date: Sat, 29 Dec 2007 15:17:49 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Kris Kennaway <kris@freebsd.org> Cc: David Xu <davidxu@freebsd.org>, current@freebsd.org Subject: Re: umtxn hang Message-ID: <20071229131749.GA57756@deviant.kiev.zoral.com.ua> In-Reply-To: <477645F1.6090502@FreeBSD.org> References: <4774467A.1050805@FreeBSD.org> <20071228130238.GT57756@deviant.kiev.zoral.com.ua> <477645F1.6090502@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--2EPcbN/asYWeYp7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 29, 2007 at 02:04:49PM +0100, Kris Kennaway wrote: > Kostik Belousov wrote: > >On Fri, Dec 28, 2007 at 01:42:34AM +0100, Kris Kennaway wrote: > >>If you run a new libc with old libthr, then applications using malloc= =20 > >>will hang in the umtxn state. This is because Jason made some changes= =20 > >>to malloc that depend on changes to libthr. The problem is that the=20 > >>binary is unkillable, which means that presumably any binary making the= =20 > >>same syscall would be unkillable. This looks like a bug to me. > >> > >># ./ebizzy -t 8 -s 1050000 > >>load: 1.09 cmd: ebizzy 42 [umtxn] 0.01u 0.00s 0% 11000k > >>[halt sent] > >>KDB: enter: Line break on console > >>[thread pid 11 tid 100008 ] > >>Stopped at kdb_enter+0x32: leave > >>db> bt 42 > >>Tracing pid 42 tid 100063 td 0xc7b71440 > >>sched_switch(c7b71440,0,1,c0bd5f80,5ab8011a,...) at sched_switch+0x360 > >>mi_switch(1,0,c7b66aa8,0,c7b66aa8,...) at mi_switch+0x137 > >>sleepq_switch(c7b71440,0,c0ac0f6e,19c,c79f7940,...) at sleepq_switch+0x= 89 > >>sleepq_catch_signals(0,c0ac0f6e,156,100,0,...) at=20 > >>sleepq_catch_signals+0x187 > > ^^^ this is PCATCH > >>sleepq_wait_sig(c79f7940,c0bce5f0,c0abeffd,100,0,...) at=20 > >>sleepq_wait_sig+0x14 > >>_sleep(c79f7940,c0bce5f0,100,c0abeffd,0,...) at _sleep+0x299 > >>_do_lock_umutex(0,0,2808e540,c7b71440,0,...) at _do_lock_umutex+0x35a > >>do_lock_umutex(0,c0a2a832,c7b6c090,c0ae44e2,31b) at do_lock_umutex+0x4d > >>__umtx_op_lock_umutex(c7b71440,e92c5cfc,e92c5d2c,c0a2ab73,c7b71440,...)= =20 > >>at __umtx_op_lock_umutex+0x50 > >>_umtx_op(c7b71440,e92c5cfc,14,e92c5d38,c0b66dd0,...) at _umtx_op+0x27 > >>syscall(e92c5d38) at syscall+0x293 > >>Xint0x80_syscall() at Xint0x80_syscall+0x20 > >>--- syscall (454, FreeBSD ELF32, _umtx_op), eip =3D 0x280d40cb, esp =3D= =20 > >>0xbfbfe87c, ebp =3D 0xbfbfe898 --- > > > >Are you sure that the process is unkillable ? Kernel code restarts the > >wait after delivery of any signal. So, the catched signal could make > >the appearance of the ignored one. From the code, it seems that kill -9 > >shall work. >=20 > OK, kill 9 from DDB worked. I just couldn't send any signals inline=20 > (^\), etc. As I said, to close the issue it would be nice to check that: - kill -9 from the shell prompt works; - the process in question did intercepted the SIGQUIT. --2EPcbN/asYWeYp7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHdkj9C3+MBN1Mb4gRAkrmAJ9u/zjjFc/grJmChWAT7S4nefiVwQCgl4vV TZfFsAGq3mp/sn4rghVF/LY= =EPhL -----END PGP SIGNATURE----- --2EPcbN/asYWeYp7O--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071229131749.GA57756>