From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4225 invoked by alias); 11 Jan 2014 12:07:43 -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 4200 invoked by uid 89); 11 Jan 2014 12:07:42 -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; Sat, 11 Jan 2014 12:07:42 +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 DED924B631; Sat, 11 Jan 2014 13:07:37 +0100 (CET) Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000) id A5D105F76B; Sat, 11 Jan 2014 13:07:37 +0100 (CET) Date: Sat, 11 Jan 2014 12:07: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: <20140111120737.GC20558@domone.podge> References: <20131009200534.GA4300@domone.podge> <201401021718.23793.vapier@gentoo.org> <20140102235440.GB5026@domone> <201401022107.03048.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201401022107.03048.vapier@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2014-01/txt/msg00034.txt.bz2 On Thu, Jan 02, 2014 at 09:07:02PM -0500, Mike Frysinger wrote: > On Thursday 02 January 2014 18:54:40 Ondřej Bílka wrote: > > 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. > > that's not what i meant. rather than make the call to reset in the child as > the code in the tree does now, if you grab the lock early, why not use the > normal unlock call in the child ? struct state would be fine. > possible. > > > 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. > > i think we want to support it without it being completely terrible. > > maybe the answer here is to reset all the dl state like we do with the lock ? > is there some init func we could call ? i'm really not familiar with glibc > ldso internals. How would you handle dlclose with handle before fork? I still do not see a clean solution.