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

[bugzilla-daemon]

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

GitLab Migration User  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #9 from GitLab Migration User  ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/990.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

--- Comment #8 from Emil Velikov  ---
Did anyone find the time to bisect ? I won't mind reverting any of my commits
but I'd like to know which one as I cannot really test this here.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

Matthias Schuster shaloksha...@riseup.net changed:

   What|Removed |Added

   Priority|medium  |high
   Severity|normal  |major

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

Eero Tamminen eero.t.tammi...@intel.com changed:

   What|Removed |Added

 CC||eero.t.tammi...@intel.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

--- Comment #7 from Eero Tamminen eero.t.tammi...@intel.com ---
latrace tool could tell something useful:
http://people.redhat.com/jolsa/latrace/

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

--- Comment #4 from Timo R. t...@rothenpieler.org ---
 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.

 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.

 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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

--- Comment #5 from Francisco Jerez curroje...@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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

--- Comment #3 from Francisco Jerez curroje...@riseup.net ---
(In reply to Tobias Jakobi from comment #2)
 Created attachment 117708 [details] [review]
 hack fix
 
 Untested hack/fix that is also not thread-safe.

That's unlikely to work, static local variables are no different to globals
regarding initialization order, 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.

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

--- Comment #6 from Serge Martin edb+freedesk...@sigluy.net ---
Hello

This remind me this. Something similar have happen to ocl-icd, see 
https://bugzilla.redhat.com/show_bug.cgi?id=1219646

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

--- Comment #2 from Tobias Jakobi liquid.a...@gmx.net ---
Created attachment 117708
  -- https://bugs.freedesktop.org/attachment.cgi?id=117708action=edit
hack fix

Untested hack/fix that is also not thread-safe.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

Bug ID: 91646
   Summary: dlopen'ing libudev.so.1 from static library
initializer corrupts TLS state
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: t...@rothenpieler.org
QA Contact: mesa-dev@lists.freedesktop.org

This is directly related to the following glibc bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=15199

Something in mesa somewhere dlopens libudev.so.1 from within the early library
initializer, which causes the TLS state in glibc to get corrupted if the
application or some later library links against libudev.so.1.

The result of this is that the next time something uses a thread-local
variable, it runs into an infinite loop in tls_get_addr_tail.

As a workaround I built mesa with gallium disabled, which made it work for my
case.
The application triggering this behaviour was kodi, but everything that
directly or indirectly links against mesa and libudev is potentialy affected,
depending on the library load order.

I'm not 100% sure if this is actualy a bug in glibc, or doing dlopen from
within a static library initializer is not well defined, but it's definitely
something that needs addressing.

Encountered this with latest mesa git, never had that problem before with any
release version.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

--- Comment #1 from Tobias Jakobi liquid.a...@gmx.net ---
The problem seems to originate from here:
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/clover/api/platform.cpp#n29

The platform object is created during static initialization and somewhere in
the class hierarchy a dlopen() is triggered. Since _clover_platform only seems
to be used in clGetPlatformIDs(), my idea would be to make this object static
and put it into the function itself, so it only gets initialization when the
function is first called.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev