Thank you for the patch. Since we are ok with simply not getting the stack trace in some cases, we decided to implement our own trampoline version of dl_iterate_phdr that simply records in a thread-local variable that it is being invoked and then forwards onto the real implementation. Then, in the signal handler, we check the thread-local variable and don't call into libunwind if dl_iterate_phdr is currently being called on the thread we're running on.
~Jared On Wed, Feb 24, 2016 at 5:20 AM, Milian Wolff <[email protected]> wrote: > On Dienstag, 23. Februar 2016 17:41:55 CET Jonathan Byrd wrote: > > On Mon, 22 Feb 2016 at 16:10:51 Arun Sharma wrote: > > > The only known work around is to > > > implement your own dl_iterate_phdr that doesn't call malloc by hooking > > > into low level APIs that notify you every time a new shared object is > > > loaded. > > > > The attached patch adds the function 'unw_set_iterate_phdr_function' to > > the libunwind API, allowing a custom implementation of dl_iterate_phdr() > > to be hooked in. That implementation would need to maintain a local > > cache (or however else you wanted to manage it) to remove the need for > > taking the glibc loader lock. > > Nice, I played around with this patch yesterday and it seems to work quite > nicely. In my implementation, I cached the results from a dl_iterate_phdr > call > which seems to stay valid until the next dlopen/dlclose call is issued, at > which point I invalidate the cache and update it on demand the next time > then. > > For my use-case (heaptrack) I think I'll be able to leverage this to gain a > considerable performance boost: Instead of serializing the individual > iterations, I should be able to use a shared mutex. I.e. only updating the > cache as a write operation must be serialized while the read operations > can be > done in parallel. > > So +1 from my side to get this patch in. > > Cheers! > > -- > Milian Wolff > [email protected] > http://milianw.de > _______________________________________________ > Libunwind-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/libunwind-devel > >
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
