patch 1/2 debuginfod client

Mark Wielaard
Wed Nov 20 12:50:00 GMT 2019


On Tue, 2019-11-19 at 16:22 -0500, Frank Ch. Eigler wrote:
> 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.

But it isn't just about interference with other libcurl activity. If
you look at the curl_global_init code you see that it actually calls a
lot of code in other libraries. It is the curl_global_init code that
shouldn't be run in a multi-threaded environment. That it is acceptable
to others doesn't immediately make it safe to use in our case. We are
slowly trying to make into a multi-tread safe library and do
expect it to be used in multi-threaded code. We aren't fully there yet.
But it would be a shame to introduce more issues if we can prevent it.

> > > > That is why I think doing the dlopen of eagerly from a
> > > > 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
> > > itself.
> > 
> > It could, but I think that would be unlikely. We can at least document
> > that it is unsafe to use with dlopen. But if it is done,
> > could we detect it and not do the loading of in that
> > case?
> I don't know how to do that.

I assume you mean the second part. The attached is what I would propose
for the first part. Do you think that is a bad idea?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: debuginfod-client-dwfl-early-init.patch
Type: text/x-patch
Size: 2565 bytes
Desc: not available
URL: <>

More information about the Elfutils-devel mailing list