Date: Mon, 09 Mar 2015 19:00:25 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 198452] libthr/rtld deadlock Message-ID: <bug-198452-16-mCRzqUdL7t@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 #3 from Konstantin Belousov <kib@FreeBSD.org> --- (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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-198452-16-mCRzqUdL7t>