[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160113110937.GE13558@port70.net>
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.
