From owner-freebsd-threads@FreeBSD.ORG Mon Mar 9 18:10:14 2015 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3285CA4B for ; Mon, 9 Mar 2015 18:10:14 +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 19666FBC for ; Mon, 9 Mar 2015 18:10:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t29IADKT076762 for ; Mon, 9 Mar 2015 18:10:13 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 18:10:14 +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: dpejesh@yahoo.com 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 18:10:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198452 --- Comment #2 from dpejesh@yahoo.com --- > Dlopen/dlclose cannot work in the context of the dl_iterate_phdr(3) callback. > At least, because the dl_iterate_phdr() walks over the list of the loaded > shared objects, so in the language terms, it is the iterator over collection, > and collection must be stable. The callback API does not suppose a > possibitily of restart. That makes sense, but this use to work pre-10.0 and currently works on Linux. It shouldn't be difficult to work around, but the new behavior seems like a regression which is why I opened the ticket. I can understand dlopen() failing if it has to load a new shared object and update its internal list, but if it's already loaded all it should need to do is update the counters and still return the handle, right? > That said, callback is intended to perform some lookups on the per object > basis, e.g. enumerate exception tables, debug sections and like. > The revisions you point out as causing the problem obviously mean that this > never worked anyway. Not sure why you're saying that. Before r245630 it worked, and reverting that change on HEAD fixes it too. It also works when not linked to libthr both before and after r245630. -- You are receiving this mail because: You are the assignee for the bug.