On Fri, Sep 25, 2009 at 1:11 PM, Paul Pluzhnikov <[email protected]> wrote:
> The remaining sigprocmask calls are following this pattern: > > sigprocmask (SIG_SETMASK, &unwi_full_mask, &saved_mask); > ret = dl_iterate_phdr (check_callback, as); > sigprocmask (SIG_SETMASK, &saved_mask, NULL); > > so (AFAICT) they wouldn't unblock anything that was blocked before. This is a well known deadlock that makes libunwind unusable for many users (who are not brave enough to implement their own dl_iterate_phdr that is async signal safe). The sigprocmask there isn't really fixing the problem. The case where libunwind gets a deadlock today is: * We're executing dynamic linker code, holding a lock * We get an async signal * The signal handler calls libunwind * libunwind blocks signals, but its too late * dl_iterate_phdr tries to grab a lock that this thread is already holding. This leads to a deadlock. Which brings up the question of why not drop this sigprocmask completely since it's not helping? How about a different approach to the problem? Abort the unwind in the unlikely event that we were holding the dl lock? Not sure if glibc exposes dl_load_lock. -Arun PS: References I could find on this topic: http://sources.redhat.com/ml/libc-hacker/2004-04/msg00001.html http://sourceware.org/ml/libc-hacker/2004-11/msg00006.html _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
