Re: [Libunwind-devel] [PATCH] Re: dl_iterate_phdr deadlock in unw_step

[Jared Cantwell]

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 <address@hidden> 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
address@hidden
http://milianw.de
_______________________________________________
Libunwind-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/libunwind-devel