Re: umtxn hang

On Sat, Dec 29, 2007 at 02:04:49PM +0100, Kris Kennaway wrote:
> 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.

As I said, to close the issue it would be nice to check that:
- kill -9 from the shell prompt works;
- the process in question did intercepted the SIGQUIT.