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
