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
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: umtxn hang
    ... to malloc that depend on changes to libthr. ... Kernel code restarts the ... kill 9 from DDB worked. ... I just couldn't send any signals inline ...
    (freebsd-current)
  • Re: [SLE] KILL in 9.3 not killing process
    ... work, opening a terminal and using kill (pid number) doesn't work, nor ... When a program receives a signal, the signal handler for that signal is ... For most signals that ...
    (SuSE)
  • Re: Periodic Fedora 9 system hangs with jumpy mouse
    ... kill -TERM ... just to make sure it wasn't sending signals. ... Other than the Xorg process, ... a running state consuming 100% cpu; ...
    (Fedora)
  • Re: signals generated ONLY by abort, kill, or raise
    ... > KNOW that the signal was generated by abort, kill, or raise? ... > It seems to me that there are only four portable signals that can ONLY be ...
    (comp.unix.programmer)
  • Re: [SLE] KILL in 9.3 not killing process
    ... work, opening a terminal and using kill (pid number) doesn't work, nor ... When a program receives a signal, the signal handler for that signal is ... For most signals that ...
    (SuSE)