[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

            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 at lists.freedesktop.org
          Reporter: timo at rothenpieler.org
        QA Contact: mesa-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150815/8066e11d/attachment.html>