[Mesa-dev] [Bug 91646] dlopen'ing libudev.so.1 from static library initializer corrupts TLS state

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91646

--- Comment #5 from Francisco Jerez <currojerez at riseup.net> ---
(In reply to Timo R. from comment #4)
> > 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.
> 

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.

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

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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150816/181b7211/attachment.html>