[Top][All Lists]
[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: |
Paul Pluzhnikov |
Subject: |
Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals. |
Date: |
Fri, 25 Sep 2009 13:11:15 -0700 |
On Fri, Sep 25, 2009 at 12:00 PM, Mark Rabkin <address@hidden> wrote:
> I read this:
> http://lists.nongnu.org/archive/html/libunwind-devel/2009-09/msg00000.html
>
> But I was a little unclear on the main motivation.
>
> Was the motivation that the existing signal blocking mechanism didn't
> prevent re-entry? If it didn't prevent it, did it cause crashes or aborted
> stack traces or what was the symptom?
Existing mechanism did prevent re-entry, but at a cost of lots of
sigprocmask()s. We have one particular (emulated) environment, where these
are quite costly.
> If you're now planning to block additional signals in your own client code
> ("at the top level"),
We don't actually need to block them, we just need to make sure that the
same thread doesn't reenter libunwind from a signal handler....
> are you removing the calls inside libunwind to ensure
> it doesn't unblock them (as it does SETMASK),
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.
But I see now that I should have eliminated these remaining sigprocmasks
as well. Patch attached.
> or are you just removing them
> for performance since they're unnecessary as your initial message implies?
Yes.
> Finally, I just wanted to get a clarification on the effects of linking
> libunwind -- it was my impression that linking it may also affect the stack
> unwinding done when, for instance, a C++ exception is thrown.
Not by default. In default configuration on x86_64, I get:
nm -D src/.libs/libunwind.so | grep ' T ' | grep -v ' _U'
0000000000001380 T backtrace
So only calls to (glibc) backtrace would be affected.
Cheers,
--
Paul Pluzhnikov
libunwind-sigprocmask-20090925-2.txt
Description: Text document
- [Libunwind-devel] [patch 2/2] Allow caller to block signals., Paul Pluzhnikov, 2009/09/21
- [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Arun Sharma, 2009/09/25
- [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Paul Pluzhnikov, 2009/09/25
- [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Arun Sharma, 2009/09/25
- [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Paul Pluzhnikov, 2009/09/25
- Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Mark Rabkin, 2009/09/25
- Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Paul Pluzhnikov, 2009/09/25
- Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Mark Rabkin, 2009/09/25
- Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Arun Sharma, 2009/09/25
- Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals.,
Paul Pluzhnikov <=
- Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Arun Sharma, 2009/09/25
- Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Arun Sharma, 2009/09/25
- Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Paul Pluzhnikov, 2009/09/25
- Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Arun Sharma, 2009/09/25
- Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals., Mark Rabkin, 2009/09/25