Date: Mon, 20 Oct 2008 17:34:34 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: Vaclav Haisman <v.haisman@sh.cvut.cz> Subject: Re: Process in "uwait" state Message-ID: <200810201734.34952.jhb@freebsd.org> In-Reply-To: <48FBBFF1.3000109@sh.cvut.cz> References: <48FBBFF1.3000109@sh.cvut.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200810201734.34952.jhb>