From owner-freebsd-threads@FreeBSD.ORG Mon Apr 18 00:54:46 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 A5B8F106564A; Mon, 18 Apr 2011 00:54:46 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF6C8FC14; Mon, 18 Apr 2011 00:54:45 +0000 (UTC) Received: by qwc9 with SMTP id 9so2637334qwc.13 for ; Sun, 17 Apr 2011 17:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=3aj6+XS3Sux759LVDUb9/NKYUF/B5a+gmQP9aNoH3G4=; b=BhdRoskGuWqKrRUEKLRJlt/LDcac7Mh4rA8h9pcoHxIe/q/XUd+z6LNPvxoT1slyEo eefGS1aLdXmrC/R7v9tLdYfYjWGZjuEATq5oRe6AO+PsO3bjUsQN2UaRLckmDM1CV0RW MyrxQsNMWv24tR8ZEbsumUvQAQe84qBJqdHck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=UJQK5Z0Id2otHU0HKiBcnyq6wiDwOkj0+EvhwzLrmWLAYQLyZnHuRG6VRbtTF5P3wK VY75/u/wQ6u5iX6R2SrED7P1PFZe8yLmUzanWA7rxgy+5ji5W41gbu2yYYIRQMGKVxqh aya2jD+qc/scWhMN14qdvAX/psacQm10AxMLw= Received: by 10.224.70.206 with SMTP id e14mr2291452qaj.82.1303088085476; Sun, 17 Apr 2011 17:54:45 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id k2sm3687845qcu.31.2011.04.17.17.54.43 (version=SSLv3 cipher=OTHER); Sun, 17 Apr 2011 17:54:44 -0700 (PDT) Date: Sun, 17 Apr 2011 20:54:38 -0400 From: Alexander Kabaev To: Andriy Gapon Message-ID: <20110417205438.69235fc4@kan.dnsalias.net> In-Reply-To: <4DAB0DC4.4060504@FreeBSD.org> References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> <4DAB0DC4.4060504@FreeBSD.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/j2JDM.XEw90xCQARPs0Hy1Z"; protocol="application/pgp-signature" Cc: freebsd-threads@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 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: Mon, 18 Apr 2011 00:54:46 -0000 --Sig_/j2JDM.XEw90xCQARPs0Hy1Z Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 17 Apr 2011 18:56:52 +0300 Andriy Gapon wrote: > on 17/04/2011 18:21 Daniel Eischen said the following: > > On Sun, 17 Apr 2011, Andriy Gapon wrote: > >=20 > >> 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 > >=20 > > - The build procedure for chromium. > >=20 > > libc/[libc_r, libpthread, libthr] have always behaved that > > way since the libc/libc_r split. >=20 > 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. >=20 I would blame it, and expressly at that. -pthread is a shortcut for {-lpthread -lc} instead of just {-lc} in the place where implied libc is provided by the compiler driver and has no magic properties you want it it to have. If chromium build infrastructure circumvents that, it is only said build infrastructure to blame. --=20 Alexander Kabaev --Sig_/j2JDM.XEw90xCQARPs0Hy1Z Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFNq4vSQ6z1jMm+XZYRApBKAJ9aGRTlhM3hLJi9udq9pCfhgtjrUQCgwsWw XI3npvXN9OTU3qmsiuojyxw= =qqhI -----END PGP SIGNATURE----- --Sig_/j2JDM.XEw90xCQARPs0Hy1Z--