Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Apr 2011 18:58:07 -0400
From:      Alexander Kabaev <kabaev@gmail.com>
To:        Andriy Gapon <avg@FreeBSD.org>
Cc:        hackers@FreeBSD.org, freebsd-threads@FreeBSD.org
Subject:   Re: puzzled: fork +libthr
Message-ID:  <20110417185807.1a06347a@kan.dnsalias.net>
In-Reply-To: <4DAAFBAF.90700@FreeBSD.org>
References:  <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/4RPTx2z_gCy3dk77ArUp3nn
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sun, 17 Apr 2011 17:39:43 +0300
Andriy Gapon <avg@FreeBSD.org> 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.
> >=20
> > 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.
>=20
> 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

Why rtld would make any special allowances for libthr?! It does exactly
what it is told to do, just as it should.
--=20
Alexander Kabaev

--Sig_/4RPTx2z_gCy3dk77ArUp3nn
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)

iD8DBQFNq3CDQ6z1jMm+XZYRAgN6AJ4yIEHX69BJmHGpR7RbyLQWOSbPcQCgwpdw
A00+NB4c9I0kDFp3IBWiSTQ=
=5L07
-----END PGP SIGNATURE-----

--Sig_/4RPTx2z_gCy3dk77ArUp3nn--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110417185807.1a06347a>