Date: Wed, 13 Jan 2016 12:09:37 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: dlopen deadlock This bug i reported against glibc also affects musl: https://sourceware.org/bugzilla/show_bug.cgi?id=19448 in case of musl it's not the global load lock, but the init_fini_lock that causes the problem. the multi-threadedness detection is also problematic in do_init_fini: need_locking = has_threads if (need_locking) lock(init_fini_lock) for all deps run_ctors(dep) if (!need_locking && has_threads) need_locking = 1 lock(init_fini_lock) if (need_locking) unlock(init_fini_lock) checking for threads after ctors are run is too late if the ctors may start new threads that can dlopen libs with common deps with the currently loaded lib. one solution i can think of is to have an init_fini_lock for each dso, then the deadlock only happens if a ctor tries to dlopen its own lib (directly or indirectly) which is nonsense (the library depends on itself being loaded) (in glibc with a self-loading ctor in the same thread the second dlopen succeeds even though the ctors haven't finished running, not sure if that's better than deadlock, in any case running user code from libc is problematic, ctors vs dlopen seems to be a disaster)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.