Date: Mon, 09 Mar 2015 18:10:14 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 198452] libthr/rtld deadlock Message-ID: <bug-198452-16-mDtH4gyAb9@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-198452-16@https.bugs.freebsd.org/bugzilla/> References: <bug-198452-16@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-198452-16-mDtH4gyAb9>