From owner-freebsd-threads@FreeBSD.ORG Sat Apr 16 12:00:20 2011 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37BFC106567A for ; Sat, 16 Apr 2011 12:00:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 085D48FC1E for ; Sat, 16 Apr 2011 12:00:18 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA10404; Sat, 16 Apr 2011 14:46:32 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QB3xQ-000JQc-G0; Sat, 16 Apr 2011 14:46:32 +0300 Message-ID: <4DA98197.8060104@FreeBSD.org> Date: Sat, 16 Apr 2011 14:46:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: hackers@FreeBSD.org, freebsd-threads@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: puzzled: fork +libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 12:00:20 -0000 Guys, I am trying to debug this chromium issue: http://trillian.chruetertee.ch/chromium/ticket/13 Not sure SOCK_SEQPACKET mentioned in the ticket is an actual culprit, the problem that interests me is that pthread_cond_wait() returns EPERM where it shouldn't. That happens on stable/8. I compared ktrace of chromium on stable/8 and head. Startup traces are very similar until execution gets to one particular place. At that place stable/8 chromium executes pthread_cond_wait - I see _umtx_op(UMTX_OP_CV_WAIT) and that's where EPERM is returned. On the other hand it seems that head chromium executes something different at exactly the same place, perhaps sem_wait - I see _umtx_op(UMTX_OP_WAIT_UINT_PRIVATE). So this is puzzle #1 for me why chromimum build or run-time chooses a different thing to call/use at that place. The second puzzle is the EPERM return value itself, on stable/8. >From what I seem chromium does a bunch of forks before it gets to the place of interest. My debugging shows that those forks are "single-threaded" (i.e. code in thr_fork.c is not called). And then in a process/thread that makes that pthread_cond_wait call I see that libthr and kernel have different opinions about what current TID is. Userland part uses what is actually a kernel TID of its parent thread (the one that called fork). And given how the work is divided between userland and kernel in libthr, that mismatch leads to serious consequences. So my question is why libthr doesn't see its actual TID. Maybe some initialization code is not invoked. BTW, chromium is linked to both libc and libthr (per ldd). But it seems that there are no pthread calls up the fork chain until that pthread_cond_wait call. Maybe this could ring a bell for someone knowledgeable in the area. -- Andriy Gapon