From owner-freebsd-current@FreeBSD.ORG Sat Dec 29 13:04:52 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 2989316A41B; Sat, 29 Dec 2007 13:04:52 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 24D1913C442; Sat, 29 Dec 2007 13:04:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477645F1.6090502@FreeBSD.org> Date: Sat, 29 Dec 2007 14:04:49 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Kostik Belousov References: <4774467A.1050805@FreeBSD.org> <20071228130238.GT57756@deviant.kiev.zoral.com.ua> In-Reply-To: <20071228130238.GT57756@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 29 Dec 2007 13:04:52 -0000 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 >> will hang in the umtxn state. This is because Jason made some changes >> to malloc that depend on changes to libthr. The problem is that the >> binary is unkillable, which means that presumably any binary making the >> 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+0x89 >> sleepq_catch_signals(0,c0ac0f6e,156,100,0,...) at sleepq_catch_signals+0x187 > ^^^ this is PCATCH >> sleepq_wait_sig(c79f7940,c0bce5f0,c0abeffd,100,0,...) at >> 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,...) >> 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 = 0x280d40cb, esp = >> 0xbfbfe87c, ebp = 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. OK, kill 9 from DDB worked. I just couldn't send any signals inline (^\), etc. Kris