libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals.


From: Arun Sharma
Subject: Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals.
Date: Fri, 25 Sep 2009 14:04:43 -0700

On Fri, Sep 25, 2009 at 1:11 PM, Paul Pluzhnikov <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]