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.john...@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
