Shared-object static constructors are user code that the C library has no
control of. They are called with the GL(dl_load_lock) lock held and are
therefore prone to a deadlock if they call back into the wrong part of
ld.so. The exact call sequence is:
_dl_open -> dl_open_worker -> _dl_init -> call_init -> user code
and in the sequence above _dl_open takes the GL(dl_load_lock) lock before
calling dl_open_worker. This affects all targets.
*** Bug 19448 has been marked as a duplicate of this bug. ***
This is normally not a problem except when constructors spawn threads to do additional work, which seems like a scenario we might support. In order to support it we would have to quiesce the state of the loader, release the locks, and run the constructor. This is something we have never supported before, but could in the future.
note: deadlock can happen without thread creation from ctors:
thread 1: dlopen -> dl_load_lock -> ctor -> user_lock
thread 2: user_lock -> dlsym/dlopen/dlclose -> dl_load_lock
if calling dlsym/dlopen/dlclose/.. from a ctor is allowed
then i'd expect this to work too, but now it deadlocks.
the fix for bug 19329 added the same lock to pthread_create
so now this problem affects more code.
i opened bug 28357 for the deadlock with pthread_create.