From owner-freebsd-threads@FreeBSD.ORG Tue Oct 25 07:16:26 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 4780D16A41F; Tue, 25 Oct 2005 07:16:26 +0000 (GMT) (envelope-from sven@serv1-mk3.ilse.net) Received: from serv1-mk3.ilse.net (serv1-mk3.ilse.net [62.69.160.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id A834343D46; Tue, 25 Oct 2005 07:16:25 +0000 (GMT) (envelope-from sven@serv1-mk3.ilse.net) Received: (from sven@localhost) by serv1-mk3.ilse.net (8.12.11/8.12.11) id j9P7GJfh018622; Tue, 25 Oct 2005 09:16:19 +0200 (CEST) (envelope-from sven) Date: Tue, 25 Oct 2005 09:16:19 +0200 From: Sven Berkvens-Matthijsse To: Daniel Eischen Message-ID: <20051025071619.GS22568@ilse.net> References: <20051024144529.GP22568@ilse.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-URL: http://www.ilse.nl/ User-Agent: Mutt/1.5.9i 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: Tue, 25 Oct 2005 07:16:26 -0000 > > 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()). > > 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. What code leads you to that conclusion? All the malloc functions simply lock a spinlock, do their work, and then unlock the spinlock. If the code gets interrupted by a timer signal and the thread scheduler schedules a thread that calls fork(), the malloc system will be in an unstable state in the child process, and when the thread library calls free() itself, the spinlock will already be locked, causing free() to hang. If you decide to set __isthreaded to 0, free() will be manipulating data that was in the process of being manipulated by the parent process (and is now in a potentially unusable state). > -- > DE -- Sven