From owner-freebsd-current@FreeBSD.ORG Fri Dec 28 13:02:44 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FFB216A41B; Fri, 28 Dec 2007 13:02:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id B167713C4EF; Fri, 28 Dec 2007 13:02:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J8ErH-000AO2-Cg; Fri, 28 Dec 2007 15:02:42 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBSD2cnE034458; Fri, 28 Dec 2007 15:02:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBSD2clC034457; Fri, 28 Dec 2007 15:02:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 28 Dec 2007 15:02:38 +0200 From: Kostik Belousov To: Kris Kennaway Message-ID: <20071228130238.GT57756@deviant.kiev.zoral.com.ua> References: <4774467A.1050805@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tDg5AmReZES28+f8" Content-Disposition: inline In-Reply-To: <4774467A.1050805@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 0c824a349f07dfe35efcbc7aeaa72b30 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1971 [Dec 28 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: David Xu , current@freebsd.org Subject: Re: umtxn hang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 13:02:44 -0000 --tDg5AmReZES28+f8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > # ./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+0x89 > sleepq_catch_signals(0,c0ac0f6e,156,100,0,...) at sleepq_catch_signals+0x= 187 ^^^ 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. --tDg5AmReZES28+f8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHdPPuC3+MBN1Mb4gRAq2uAJ94j8vJSKSYZ06LAgxvdJCTVXBfngCeKWcL bYuyVhtLmXvCcb/oMHugXBo= =GVtX -----END PGP SIGNATURE----- --tDg5AmReZES28+f8--