From owner-freebsd-stable@FreeBSD.ORG Mon Oct 20 21:44:23 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64C7410656C3 for ; Mon, 20 Oct 2008 21:44:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id ED7198FC0C for ; Mon, 20 Oct 2008 21:44:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m9KLi5It096902; Mon, 20 Oct 2008 17:44:12 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 20 Oct 2008 17:34:34 -0400 User-Agent: KMail/1.9.7 References: <48FBBFF1.3000109@sh.cvut.cz> In-Reply-To: <48FBBFF1.3000109@sh.cvut.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810201734.34952.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 20 Oct 2008 17:44:16 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8451/Mon Oct 20 12:02:15 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Vaclav Haisman Subject: Re: Process in "uwait" state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2008 21:44:23 -0000 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 .), > 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