From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12541 invoked by alias); 19 Nov 2019 20:16:02 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 12350 invoked by uid 89); 19 Nov 2019 20:15:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Nov 2019 20:15:43 +0000 Received: from librem (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 55A0F302BBFD; Tue, 19 Nov 2019 21:15:25 +0100 (CET) Received: by librem (Postfix, from userid 1000) id 668CEC387A; Tue, 19 Nov 2019 21:15:20 +0100 (CET) Date: Tue, 19 Nov 2019 20:16:00 -0000 From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org, amerey@redhat.com Subject: Re: patch 1/2 debuginfod client Message-ID: <20191119201520.GB3494@wildebeest.org> References: <20191028190438.GC14349@redhat.com> <20191028190602.GD14349@redhat.com> <9bc154bce6389be9b07f2db9dcdcc605ad4f39e3.camel@klomp.org> <20191113232456.GA31583@redhat.com> <6d7430368a18c943f72bc3583efeafb2c192516f.camel@klomp.org> <20191116185256.GB19543@redhat.com> <356e88e4937ddb97a3e7cc93dbdfe29239ff960e.camel@klomp.org> <20191118203324.GD2880@redhat.com> <7ca3cc662684459fe21801344f0899f5108a8a70.camel@klomp.org> <20191119162034.GC4911@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191119162034.GC4911@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00186.txt.bz2 Hi Frank, On Tue, Nov 19, 2019 at 11:20:34AM -0500, Frank Ch. Eigler wrote: > > > Doing a redundant initialization later is not a problem; there is a > > > counter in there. The problematic case would be > > > - a multithreaded application > > > - loading debuginfod.so multiply concurrently somehow > > > - and calling the solib ctor concurrently somehow > > > - and all of this concurrently enough to defeat libcurl's init-counter > > > > > > IMHO, not worth worrying about. Someday libcurl will do the right > > > thing (tm) and plop this initialization into their solib ctor. > > > > I do worry about this because any multi-threaded app that uses libdw.so > > might cause trouble because we dlopen libdebuginfod.so lazily and then > > it will call curl_global_init () which explicitly says: > > > > This function is not thread safe. You must not call it when any > > other thread in the program (i.e. a thread sharing the same memory) > > is running. [...] > > That's what the doc says. What the code does, as far back as the year > 2001, is have a static flag/counter in curl_global_init() that > prevents multiple initialization. But the warning isn't about multiple initialization. It is about initialization when other threads are running that might be using any of the libcurl support libraries. > > That is why I think doing the dlopen of libdebuginfod.so eagerly from a > > libdw.so constructor function or _init might be necessary to make sure > > no other threads are running yet. > > That's not even enough for "sure" - if we're so deep in the > hypotheticals hole, an application could be dlopen()ing libdw.so > itself. It could, but I think that would be unlikely. We can at least document that it is unsafe to use libdw.so with dlopen. But if it is done, could we detect it and not do the loading of libdebuginfod.so in that case? Thanks, Mark