Date: Sun, 19 Oct 2008 23:17:05 +0000 From: Vaclav Haisman <v.haisman@sh.cvut.cz> To: freebsd-stable@freebsd.org Subject: Process in "uwait" state Message-ID: <48FBBFF1.3000109@sh.cvut.cz>
next in thread | raw e-mail | index | archive | help
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. 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?) So, what I would like to know/ask is: Is this kernel or TrueCrypt bug? Can I do anything about either of the two? Can I provide more information? -- VH
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48FBBFF1.3000109>