Re: Excessive calls to iterate_phdr during exception handling

[Alan Modra <amodra at gmail dot com>]

On Tue, May 28, 2013 at 09:19:48PM -0400, Ryan Johnson wrote:
> On 28/05/2013 8:47 PM, Ian Lance Taylor wrote:
> >On Mon, May 27, 2013 at 3:20 PM, Ryan Johnson
> ><ryan.johnson@cs.utoronto.ca> wrote:
> >>I'm bringing the issue up here, rather than filing a bug, because I'm not
> >>sure whether this is an oversight, a known problem that's hard to fix, or a
> >>feature (e.g. somehow required for reliable unwinding). I suspect the
> >>former, because _Unwind_Find_FDE tries a call to _Unwind_Find_registered_FDE
> >>before falling back to dl_iterate_phdr, but the former never succeeds in my
> >>trace (iterate_phdr is always called).
> >The issue is dlclose followed by dlopen.  If we had a cache ahead of
> >dl_iterate_phdr, we would need some way to clear out any information
> >cached from a dlclose'd library.  Otherwise we might pick up the old
> >information when looking up an address from a new dlopen.  So 1)
> >locking will always be required; 2) any caching system to reduce the
> >number of locks will require support for dlclose, somehow.  It's worth
> >working on but there isn't going to be a simple solution.
> I have mixed feelings on this... on the one had it would be bad to
> risk sending unwind off to la-la land because somebody did a quick
> dlclose/dlopen pair on code we're about to unwind through... but on
> the other hand anybody who does a dlclose/dlopen pair on code we're
> about to unwind through (a) is asking for trouble and (b) is
> perfectly free to do so in spite of the mutex [1].

Yes of course you can shoot yourself in the foot.  The mutex is there
to stop the glibc dl_iterate_phdr list traversal running awry when
dlopen/dlclose happens in another thread.  To be clear, I'm talking
about a dlclose on an object that your thread doesn't access.  Such a
dlclose shouldn't affect your thread in any way.  But if glibc's
list of loaded objects was allowed to change while your thread was
running dl_iterate_phdr, then dl_iterate_phdr could potentially read
freed list entries.

-- 
Alan Modra
Australia Development Lab, IBM