Re: umtxn hang

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