From owner-freebsd-threads@FreeBSD.ORG Mon Mar 9 19:00:25 2015 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4503F752 for ; Mon, 9 Mar 2015 19:00:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BACF8AE for ; Mon, 9 Mar 2015 19:00:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t29J0P6N096833 for ; Mon, 9 Mar 2015 19:00:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 198452] libthr/rtld deadlock Date: Mon, 09 Mar 2015 19:00:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:00:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198452 --- Comment #3 from Konstantin Belousov --- (In reply to dpejesh from comment #2) Technically, what happens is that dl_iterate_phdr() locks the rtld_bind_lock, and dlopen() needs the same lock. This is reasonable, since the lock protects the structures which are used by iterator and modified by dlopen(), just for example, the list of the loaded objects. Generally, we cannot upgrade read-lock to write, since there may be other read lock owners. We cannot drop read lock, to wait for write, since this invalidates previous iterations. I said that your reference to the commits is strange, because this is definitely not the commits you point out that introduces the behavior. It is there from the moment when locks were added to dl_iterate_phdr(). You are tripping on the stated revisions since that revs force to use real locking when libthr.so is loaded into the process. The single-threaded processes use some sort of fake locking in rtld. I.e. the 'bug' is there for long time. WRT Linux, their dl_iterate_phdr() is much less safe, so to say, then ours. For instance, their dl_iterate_phdr() should not be used from the signal handler context, which causes trouble for libunwind, and is one of the reasons why I do not want to change the code to e.g. dropping lock during the calls to callback and using sentinel to remember the position to iterate. -- You are receiving this mail because: You are the assignee for the bug.