From owner-freebsd-threads@FreeBSD.ORG Sun Apr 17 18:42:07 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 C4BF41065673; Sun, 17 Apr 2011 18:42:07 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 624858FC12; Sun, 17 Apr 2011 18:42:07 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p3HILvuX006335; Sun, 17 Apr 2011 14:21:57 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Sun, 17 Apr 2011 14:21:57 -0400 (EDT) Date: Sun, 17 Apr 2011 14:21:57 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Gapon In-Reply-To: <4DAB0DC4.4060504@FreeBSD.org> Message-ID: References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> <4DAB0DC4.4060504@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: puzzled: fork +libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:42:07 -0000 On Sun, 17 Apr 2011, Andriy Gapon wrote: > on 17/04/2011 18:21 Daniel Eischen said the following: >> On Sun, 17 Apr 2011, Andriy Gapon wrote: >> >>> on 16/04/2011 14:46 Andriy Gapon said the following: >>>> 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. >>> >>> The second problem seems to be caused by chrome binary being linked to libc and >>> libthr in "incorrect order", libc comes before libthr in ldd output. My >>> debugging shows that fork is resolved from libc, not from libthr. >>> Not sure what to blame here: >>> - build toolchain for putting libc before libthr >>> - rtld for not preferring libthr over libc >>> - libc/libthr for being split into two pieces in the current way >> >> - The build procedure for chromium. >> >> libc/[libc_r, libpthread, libthr] have always behaved that >> way since the libc/libc_r split. > > Well, I wouldn't blame it so expressly: -pthread is the first option on the > linkage command line, there is -lc there also. I would expect that that would > do the right thing, but it doesn't. And that's a PITA for porting. ports have been doing the right thing for years; I think they probably just remove the explicit -lc because -lc is implied. I'm not saying that you couldn't change the linker to ignore -lc, but we've gotten (so far) without it. I recall it was a little bit of work to get some ports to behave correctly, but it was very managable. But perhaps @ports has a different view of history ;-) -- DE