<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - dlopen'ing libudev.so.1 from static library initializer corrupts TLS state"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91646#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - dlopen'ing libudev.so.1 from static library initializer corrupts TLS state"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91646">bug 91646</a>
from <span class="vcard"><a class="email" href="mailto:currojerez@riseup.net" title="Francisco Jerez <currojerez@riseup.net>"> <span class="fn">Francisco Jerez</span></a>
</span></b>
<pre>(In reply to Timo R. from <a href="show_bug.cgi?id=91646#c4">comment #4</a>)
<span class="quote">> > That's unlikely to work, static local variables are no different to globals
> > regarding initialization order,
>
> To my knowledge, static local variables are initialized on the first call to
> the function, whereas global variables are initialized in the libraries
> early static initializer, which runs during library load.
> </span >
IIRC static local variables are allowed to be initialized statically under
roughly the same set of conditions in which global variables are -- That said
because the platform constructor has side-effects it looks like you're right
and the platform will necessarily have to be initialized dynamically the first
time the function is run.
<span class="quote">> > and, yeah, it seems like a hack because
> > pipe_loader_probe() shouldn't be doing anything that could corrupt the TLS
> > state when called at initialization time.
>
> The simple act of calling dlopen on libudev.so.1 from within the early
> static initializer is enough to corrupt the TLS state, but only if some
> later library also links against libudev.so.1.
> So not initializing the structure on library-load, but on first function
> call might actualy help.
> </span >
The thing is you have no guarantee that the function it's now being initialized
from will not itself be called from a static-storage variable initializer, so
assuming that the conditions you describe are enough to corrupt the TLS state
this will only be hiding the problem.
<span class="quote">> > It looks like this might be a regression from the series
> > de5c2b6f2b53924bceab6f4b8255d8e9dcad21b4..
> > cc32d25454c382a971e81ae584a4296fdf492e70(which are indeed not part of any
> > released version yet), you may want to bisect which change introduced the
> > problem.
>
> Not sure when I'll get to this, but I'll see what i can do.</span ></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>