Re: umtxn hang

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.