From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28705 invoked by alias); 2 Jan 2014 23:54:50 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 28680 invoked by uid 89); 2 Jan 2014 23:54:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_NEUTRAL autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: popelka.ms.mff.cuni.cz Received: from popelka.ms.mff.cuni.cz (HELO popelka.ms.mff.cuni.cz) (195.113.20.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 02 Jan 2014 23:54:45 +0000 Received: from domone.kolej.mff.cuni.cz (popelka.ms.mff.cuni.cz [195.113.20.131]) by popelka.ms.mff.cuni.cz (Postfix) with ESMTPS id DD15C6C2A6; Fri, 3 Jan 2014 00:54:40 +0100 (CET) Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000) id 8A3955F771; Fri, 3 Jan 2014 00:54:40 +0100 (CET) Date: Thu, 02 Jan 2014 23:54:00 -0000 From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= To: Mike Frysinger Cc: libc-alpha@sourceware.org, libc-ports@sourceware.org Subject: Re: [RFC][BZ #1874] Fix assertion triggered by thread/fork interaction Message-ID: <20140102235440.GB5026@domone> References: <20131009200534.GA4300@domone.podge> <201401021718.23793.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201401021718.23793.vapier@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2014-01/txt/msg00011.txt.bz2 On Thu, Jan 02, 2014 at 05:18:22PM -0500, Mike Frysinger wrote: > On Wednesday 09 October 2013 16:05:34 Ondřej Bílka wrote: > > Details: > > > > If a thread happens to hold dl_load_lock and have r_state set to RT_ADD > > or RT_DELETE at the time another thread calls fork(), then the child exit > > code from fork (in nptl/sysdeps/unix/sysv/linux/fork.c in our case) > > re-initializes dl_load_lock but does not restore r_state to RT_CONSISTENT. > > If the child subsequently requires ld.so functionality before calling > > exec(), then the assertion will fire. > > > > The patch acquires dl_load_lock on entry to fork() and releases it on exit > > from the parent path. The child path is initialized as currently done. > > This is essentially pthreads_atfork, but forced to be first because the > > acquisition of dl_load_lock must happen before malloc_atfork is active > > to avoid a deadlock. > > " > > doesn't seem right that we grab the lock and then just reset it in the child ? > seems like you should just unlock it rather than reset it in the child. > That part looks ok as without locking you could get inconsistent linker structures. > i'm also wary of code that already grabs a lot of locks trying to grab even > more. the code paths that already grab the IO locks ... can they possibly > grab this one too ? like a custom format handler that triggers loading of > libs ? > Do you haave a better solution? I send this to decide what to do with this bug. I would not be surprised if we decided that it is invalid as threads with fork cause problems in general.