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