Date: Sun, 17 Apr 2011 14:21:57 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: puzzled: fork +libthr Message-ID: <Pine.GSO.4.64.1104171414560.5981@sea.ntplx.net> In-Reply-To: <4DAB0DC4.4060504@FreeBSD.org> References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> <Pine.GSO.4.64.1104171119110.5365@sea.ntplx.net> <4DAB0DC4.4060504@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1104171414560.5981>