Re: patch 1/2 debuginfod client

["Frank Ch. Eigler" <fche@redhat.com>]

Hi -

On Tue, Nov 19, 2019 at 09:15:20PM +0100, Mark Wielaard wrote:
> > 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.

Since 2001, the curl_global_init function does nothing to interfere
with any libcurl activity, if the library is already initialized.  Any
call to the normal libcurl functions first calls this function.  I
guess I just fail to see a plausible problem scenario short of a
minuscule race over incrementing an initialization counter, which is a
race that every other libcurl user has accepted.


> > > 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?

I don't know how to do that.


- FChE