From owner-freebsd-threads@FreeBSD.ORG Sun Apr 17 13:35:09 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 10B7C106564A; Sun, 17 Apr 2011 13:35:09 +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 25A1A8FC13; Sun, 17 Apr 2011 13:35:07 +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 QAA21224; Sun, 17 Apr 2011 16:35:06 +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 1QBS82-000MFY-IT; Sun, 17 Apr 2011 16:35:06 +0300 Message-ID: <4DAAEC89.1090103@FreeBSD.org> Date: Sun, 17 Apr 2011 16:35:05 +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 References: <4DA98197.8060104@FreeBSD.org> In-Reply-To: <4DA98197.8060104@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: 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: Sun, 17 Apr 2011 13:35:09 -0000 on 16/04/2011 14:46 Andriy Gapon said the following: > > 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. OK, this was simple. This is because of the new userland condvar implementation in head. The call is the same pthread_cond_wait, just the different implementation in libthr. -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Sun Apr 17 14:39: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 97EE61065674; Sun, 17 Apr 2011 14:39:46 +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 AB1268FC16; Sun, 17 Apr 2011 14:39:45 +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 RAA21629; Sun, 17 Apr 2011 17:39:44 +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 1QBT8Z-000MGx-TU; Sun, 17 Apr 2011 17:39:43 +0300 Message-ID: <4DAAFBAF.90700@FreeBSD.org> Date: Sun, 17 Apr 2011 17:39:43 +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 References: <4DA98197.8060104@FreeBSD.org> In-Reply-To: <4DA98197.8060104@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: 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: Sun, 17 Apr 2011 14:39:46 -0000 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 -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Sun Apr 17 15: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 D4F6E1065672; Sun, 17 Apr 2011 15:42:07 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4A28FC0C; Sun, 17 Apr 2011 15: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 p3HFL7Um024525; Sun, 17 Apr 2011 11:21:07 -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 11:21:07 -0400 (EDT) Date: Sun, 17 Apr 2011 11:21:07 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Gapon In-Reply-To: <4DAAFBAF.90700@FreeBSD.org> Message-ID: References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 15:42:07 -0000 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. -- DE From owner-freebsd-threads@FreeBSD.ORG Sun Apr 17 15:56:58 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 10B3A1065694; Sun, 17 Apr 2011 15:56:58 +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 23A518FC17; Sun, 17 Apr 2011 15:56:56 +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 SAA22261; Sun, 17 Apr 2011 18:56:53 +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 1QBULF-000MIi-CZ; Sun, 17 Apr 2011 18:56:53 +0300 Message-ID: <4DAB0DC4.4060504@FreeBSD.org> Date: Sun, 17 Apr 2011 18:56:52 +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: Daniel Eischen References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 15:56:58 -0000 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. -- Andriy Gapon 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 From owner-freebsd-threads@FreeBSD.ORG Sun Apr 17 23:22:27 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 0078E1065673; Sun, 17 Apr 2011 23:22:27 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6DCE08FC14; Sun, 17 Apr 2011 23:22:26 +0000 (UTC) Received: by vws18 with SMTP id 18so4067190vws.13 for ; Sun, 17 Apr 2011 16:22:25 -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=/R20/6IpQBNTb1NhS8o97alWsvXPGA10n7sVlJgjSEo=; b=wT7pm+VrVubl+sydBP2jo3b9wHz0h+E59Cfnva2qvOlD5Lza7m5iGerApwrV6KJKGo ZtWEj+vdm6GUdrqj3Qqy98wsFCevPw1xcoydl+zk/45jpfFrEUrahwjvZtSlMSjmxouQ lLQrNU3iLXZZikmCjGqn6rpIDrV/MjFZ0781g= 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=sv4cLnf8TOd2pxTos6gEO08GCjUykDM6+xZtXXy0wQ6EcjD3+kamE+F+uF4mR1U4Tq iST/D0Pm5Px9AUtimrtKhoBfl6bakGxH1RzTLCTC9/J7BGLYRyxj/9NNecO3rD9iv8Yk M36k2FeJviE+1IrG0IVPCLLKJQdkeczN+6FgU= Received: by 10.52.173.168 with SMTP id bl8mr2078721vdc.106.1303081094508; Sun, 17 Apr 2011 15:58:14 -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 h23sm3000284vbz.21.2011.04.17.15.58.12 (version=SSLv3 cipher=OTHER); Sun, 17 Apr 2011 15:58:13 -0700 (PDT) Date: Sun, 17 Apr 2011 18:58:07 -0400 From: Alexander Kabaev To: Andriy Gapon Message-ID: <20110417185807.1a06347a@kan.dnsalias.net> In-Reply-To: <4DAAFBAF.90700@FreeBSD.org> References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@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_/4RPTx2z_gCy3dk77ArUp3nn"; protocol="application/pgp-signature" 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:22:27 -0000 --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 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-- 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-- From owner-freebsd-threads@FreeBSD.ORG Mon Apr 18 06:24:17 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 5EBAB106566B; Mon, 18 Apr 2011 06:24:17 +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 675698FC13; Mon, 18 Apr 2011 06:24:16 +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 JAA03098; Mon, 18 Apr 2011 09:24:11 +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 1QBhsZ-000Ozc-J8; Mon, 18 Apr 2011 09:24:11 +0300 Message-ID: <4DABD90A.1080402@FreeBSD.org> Date: Mon, 18 Apr 2011 09:24:10 +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: Alexander Kabaev References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> <4DAB0DC4.4060504@FreeBSD.org> <20110417205438.69235fc4@kan.dnsalias.net> In-Reply-To: <20110417205438.69235fc4@kan.dnsalias.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 06:24:17 -0000 on 18/04/2011 03:54 Alexander Kabaev said the following: > > 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. OK, I see, thank you. Still inconvenient. As in: if we know for a fact that "gcc ... -pthread -lc" results in a broken binary, then IMO we should do something about that. -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Mon Apr 18 11:07:11 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 B74401065675 for ; Mon, 18 Apr 2011 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 89A4F8FC1D for ; Mon, 18 Apr 2011 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p3IB7Bu5019643 for ; Mon, 18 Apr 2011 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p3IB7A2k019641 for freebsd-threads@FreeBSD.org; Mon, 18 Apr 2011 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Apr 2011 11:07:10 GMT Message-Id: <201104181107.p3IB7A2k019641@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org 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 11:07:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/154893 threads pthread_sigmask don't work if mask and oldmask are pas o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/149366 threads pthread_cleanup_pop never runs the configured routine o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r s threa/69020 threads pthreads library leaks _gc_mutex s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/34536 threads accept() blocks other threads s threa/30464 threads [patch] pthread mutex attributes -- pshared 27 problems total.