[Bug dynamic-link/19448] deadlock in dlopen when ctor calls dlopen in another thread

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
This is another case of dlopen being synchronously reentered by another context
of execution, but in this case there is no easy fix (like there was in the case
of an interposed malloc that calls dlopen itself).

The constructor is essentially a foreign function being called while holding
the load lock, and when you recursively enter dlopen again from another thread,
you get a deadlock.

Siddhesh and I talked about this at one point last year and the consensus among
us was that we can't fix this without rewriting the dynamic load routines to
use atomic operations and remove all instances of the load lock. Doing so would
simplify a lot of the other problems we have (we would also remove lazy TLS
allocation to fix the AS-safe issue calling malloc when accessing TLS variables
for the first time in signal handlers).

-- 
You are receiving this mail because:
You are on the CC list for the bug.