From owner-freebsd-threads@FreeBSD.ORG Mon Oct 24 14:00:36 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 84D6016A475; Mon, 24 Oct 2005 14:00:36 +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 F3E0C43D55; Mon, 24 Oct 2005 14:00:31 +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 j9OE0NcU049284; Mon, 24 Oct 2005 16:00:23 +0200 (CEST) (envelope-from sven) Date: Mon, 24 Oct 2005 16:00:23 +0200 From: Sven Berkvens-Matthijsse To: Daniel Eischen Message-ID: <20051024140023.GM22568@ilse.net> References: <20051024121145.GB25866@stack.nl> 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 , Marc Olzheim , David Xu , freebsd-threads@freebsd.org 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 14:00:37 -0000 > I'm not interested in maintaining libc_r, but I looked at the fix. > It exports symbols into the application namespace (those without > leading underscores). It does (which I can fix if you'd like). The reason is that I only changed the names of those mutexes and spinlocks that were called "thread_lock". I'm lazy, I know :-) > It also looks to me like an application bug since you can only use > async signal safe functions in the child after a fork() from a > threaded application and before an exec() of some sort. That's correct, but the libc_r library calls free() itself to clean up after all threads other than the current one (which according to the specs don't exist in a forked program). So it's a bug in the library, I guess, because it calls non-async-signal-safe functions itself. See /usr/src/lib/libc_r/uthread/uthread_fork.c, in which the freeing happens. > -- > DE -- Sven