From owner-freebsd-stable@FreeBSD.ORG Sun Oct 19 21:44:56 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 F13451065672 for ; Sun, 19 Oct 2008 21:44:56 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from service2.sh.cvut.cz (service2.sh.cvut.cz [147.32.127.218]) by mx1.freebsd.org (Postfix) with ESMTP id 82C548FC08 for ; Sun, 19 Oct 2008 21:44:56 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service2.sh.cvut.cz (Postfix) with ESMTP id 9B90B3BE54; Sun, 19 Oct 2008 23:17:31 +0200 (CEST) Received: from service2.sh.cvut.cz ([127.0.0.1]) by localhost (service2.sh.cvut.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28816-03; Sun, 19 Oct 2008 23:17:24 +0200 (CEST) Received: from amber2.local (35.201.broadband4.iol.cz [85.71.201.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by service2.sh.cvut.cz (Postfix) with ESMTP id 0D6F73BE22; Sun, 19 Oct 2008 23:17:24 +0200 (CEST) Message-ID: <48FBBFF1.3000109@sh.cvut.cz> Date: Sun, 19 Oct 2008 23:17:05 +0000 From: Vaclav Haisman User-Agent: Thunderbird 2.0.0.17 (X11/20081017) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.7 OpenPGP: id=63B6B297 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at service2.sh.cvut.cz X-Spam-Status: No, hits=4.6 tagged_above=-255.0 required=5.0 tests=AWL, BOTNET, CRM114_SPAM_00, FORGED_RCVD_HELO, JR_RCVD_HOST_PROBS1, JR_RCVD_TOO_FEW_HOPS X-Spam-Level: **** Subject: 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: Sun, 19 Oct 2008 21:44:57 -0000 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. 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