umtxn hang

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
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 ---

Kris