Hi Arun, Thank you for the quick reply!
Please help us with these follow-up questions: 1. Since we are not calling libunwind from inside the signal handler, why is it an issue that dl_iterate_phdr() is not async-signal-safe? 2. Would you elaborate on the reason(s) why per-thread caching in libunwind (along the lines of IA64) is not sufficient? We would like to fully understand the issues here and the challenges that we are bound to face if we go down that path. Please provide us with some pointers as this will potentially save us weeks of qualification effort. 3. Would you confirm our understanding that on Linux, the PER_THREAD option is implemented as no-thread option? Thanks and Regards, Prabhat From: [email protected] [mailto:[email protected]] On Behalf Of Arun Sharma Sent: Tuesday, January 08, 2013 6:27 PM To: Prabhat Verma Cc: [email protected] Subject: Re: [Libunwind-devel] UNW_CACHE_PER_THREAD On Tue, Jan 8, 2013 at 2:33 PM, Prabhat Verma <[email protected]<mailto:[email protected]>> wrote: malloc observe_malloc - our malloc hook unwind_stack - Linux libunwind implementation unw_step (takes libunwind CACHE lock) dl_interate_hdr (takes dl lock) The same deadlock may happen while THREAD 1 is in dlsym and other dl functions that all internally use the same recursive lock dl lock and allocate memory. This is a well known issue. dl_iterate_phdr in glibc is not async signal safe. So it's not safe to call from libunwind. One solution is to patch your glibc to make it async signal safe (trade-off: allocate all the needed memory upfront or using async signal safe APIs and use atomics where possible). It's not trivial, but not impossible either. Other solutions can mask this problem, but on a large enough dataset, this issue will manifest in other ways. -Arun
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
