[Bug 198452] libthr/rtld deadlock

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198452

--- Comment #3 from Konstantin Belousov <kib at 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.