Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Jan 2016 12:09:37 +0100
From: Szabolcs Nagy <>
Subject: dlopen deadlock

This bug i reported against glibc also affects musl:

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

	need_locking = has_threads
	if (need_locking)
	for all deps
		if (!need_locking && has_threads)
			need_locking = 1
	if (need_locking)

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

(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.