From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9105 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: dlopen deadlock Date: Wed, 13 Jan 2016 12:09:37 +0100 Message-ID: <20160113110937.GE13558@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1452683405 18843 80.91.229.3 (13 Jan 2016 11:10:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jan 2016 11:10:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9118-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 13 12:10:04 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aJJJO-0005lv-LN for gllmg-musl@m.gmane.org; Wed, 13 Jan 2016 12:09:58 +0100 Original-Received: (qmail 5368 invoked by uid 550); 13 Jan 2016 11:09:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5312 invoked from network); 13 Jan 2016 11:09:49 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9105 Archived-At: 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)