Process in "uwait" state

[John Baldwin]

On Sunday 19 October 2008 07:17:05 pm Vaclav Haisman wrote:
> Hi,
> I am trying to compile TrueCrypt 6.0a (The tweaked port source is
> available at <http://shell.sh.cvut.cz/~wilx/truecrypt-port-6.0a.tbz>.),
> using Miwi's 5.0 port as base, and everything goes smooth up to the
> point where the truecrypt executable is being tested. It executes
> another instance and it is apparently connected through pipe with the
> first. The following is output of ps -lax | grep truecrypt:
> 
>     0 81007 77821   0   8  0  3464  1476 wait   I+    p0    0:00.00
> /bin/sh -c ./truecrypt --text --test >/dev/null
>     0 81008 81007   0  96  0 39224 17272 uwait  I+    p0    0:00.20
> ./truecrypt --text --test
>     0 81009 81008   0  -8  0 37176 14228 piperd I+    p0    0:00.00
> ./truecrypt --text --test
> 
> This is 7.1-PRERELEASE updated no more than week ago. I am running the
> GENERIC kernel. The situation is reliably reproducible.
> 
> The last few lines of the process' ktrace, before it gets stuck, are these:
> 
>  87530 truecrypt CALL  sigprocmask(SIG_BLOCK,0x282ebb00,0xbfbfdbcc)
>  87530 truecrypt RET   sigprocmask 0
>  87530 truecrypt CALL  sigprocmask(SIG_SETMASK,0x282ebb10,0)
>  87530 truecrypt RET   sigprocmask 0
>  87530 truecrypt CALL  _umtx_op(0xbfbfde9c,0x3,0x1,0,0)
>  87530 truecrypt RET   _umtx_op 0
>  87530 truecrypt CALL  sigprocmask(SIG_BLOCK,0xbfbfde30,0x8401190)
>  87530 truecrypt RET   sigprocmask 0
>  87530 truecrypt CALL  _umtx_op(0x85e6e8c,0x2,0,0,0)
> 
> The _umtx_op(0x85e6e8c,0x2,0,0,0) call is the last thing, after that I
> have to kill it with kill -9.

Probably an application threading bug.  This looks like the thread is waiting 
on a condition variable.

> Attaching GDB to the process does not help much, GDB complains about
> some internal error and the backtrace is then unusable:
> 
> /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1443:
> internal-error: legacy_fetch_link_map_offsets called without legacy
> link_map support enabled.
> 
> [Switching to Thread 0x8401100 (LWP 100173)]
> 0x28a9a037 in __error () from /lib/libthr.so.3
> (gdb) bt
> #0  0x28a9a037 in __error () from /lib/libthr.so.3
> #1  0x28a99c71 in __error () from /lib/libthr.so.3
> #2  0x085e6e8c in ?? ()
> #3  0x00000002 in ?? ()
> #4  0x00000000 in ?? ()
> #5  0x00000000 in ?? ()
> #6  0x00000000 in ?? ()
> #7  0x00000040 in ?? ()
> #8  0xbfbfdda4 in ?? ()
> #9  0x28a94bb7 in pthread_rwlock_unlock () from /lib/libthr.so.3
> Previous frame identical to this frame (corrupt stack?)

Give gdb the path to the binary in addition to the pid and you won't get that 
error message and will get a more useful stack trace.

-- 
John Baldwin