Date: Sat, 29 Dec 2007 14:04:49 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: David Xu <davidxu@freebsd.org>, current@freebsd.org Subject: Re: umtxn hang Message-ID: <477645F1.6090502@FreeBSD.org> In-Reply-To: <20071228130238.GT57756@deviant.kiev.zoral.com.ua> References: <4774467A.1050805@FreeBSD.org> <20071228130238.GT57756@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477645F1.6090502>