From owner-freebsd-threads@FreeBSD.ORG Mon Oct 24 16:58:54 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B8B416A41F; Mon, 24 Oct 2005 16:58:54 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCBD043D46; Mon, 24 Oct 2005 16:58:53 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 63CC1A2FF2; Mon, 24 Oct 2005 18:58:50 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 44980644A; Mon, 24 Oct 2005 18:58:50 +0200 (CEST) Date: Mon, 24 Oct 2005 18:58:50 +0200 From: Marc Olzheim To: Daniel Eischen Message-ID: <20051024165850.GA28694@stack.nl> References: <20051024144529.GP22568@ilse.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD hammer.stack.nl 6.0-BETA4 FreeBSD 6.0-BETA4 X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.11 Cc: Marc Olzheim , freebsd-threads@freebsd.org, Marc Olzheim , David Xu , Sven Berkvens-Matthijsse Subject: Re: threads/76690: fork hang in child for (-lc_r & -lthr) 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, 24 Oct 2005 16:58:54 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 24, 2005 at 12:41:01PM -0400, Daniel Eischen wrote: > > But then the free() in the child process may be using an unstable > > state of the malloc system (because if you don't acquire the lock > > before the fork(), malloc() may be busy in the middle of the fork()). >=20 > I don't think that can happen because libc_r will not switch out > a thread that is in a critical region (and libc locks are critical > regions) until it leaves the region. Well, that would be the idea, but GDB traces prove otherwise... :P And that's why the patch prevents the test program in the PR from hanging. Marc --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDXRLKezjnobFOgrERAukqAJ4shbzfmw0/lTJVx5gFji4OuRY0eQCgwBl4 pjkKgtYjRuELVkcc4X6e/fU= =C/QT -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA--