Re: determine whether code is running in a signal handler context

[Will Hawkins <whh8b at virginia dot edu>]

On Wednesday, October 18, 2017, Carlos O'Donell <carlos@redhat.com> wrote:

> On 10/18/2017 06:52 PM, Yubin Ruan wrote:
> > 2017-10-19 2:34 GMT+08:00 Carlos O'Donell <carlos@redhat.com
> <javascript:;>>:
> >> On 10/18/2017 07:18 AM, Yubin Ruan wrote:
> >>> Hi,
> >>>
> >>> I am writing to see if this is any util functions in libc that can
> >>> help to determine it is currently running in a signal.
> >>>
> >>> I wrote some library and provide a function which will be used in many
> >>> client code. However this function is not async-signal safe (it calls
> >>> malloc(3)) so when it is called, I want to detect whether it is
> >>> currently running in a signal handler. If it is, I can avoid calling
> >>> those not-async-signal-safe functions which might cause deadlock.
> >>>
> >>> that is, I want a `in_signal_handler_context()' utility that can be
> >>> used as this:
> >>>
> >>> int mylibfunc( void ) {
> >>>     if( in_signal_handler_context() ) { return(-1) }
> >>>     // rest of function goes here
> >>>     return( 0 );
> >>> }
> >>
> >> Only (b).
> >>
> >> (a) The kernel knows, but doesn't tell you.
> >>
> >> (b) Only via architecture-specific checks which involve inspecting the
> >>     call frame to determine if there is a signal frame on the stack.
> >
> > Is (b) deterministic? How can we know whether a call frame is a signal
> > frame and how can we know at which point we should stop when
> > inspecting the frame?
>
> We could spend days talking about this. The answer should be deterministic,
> and gdb solves it, but the solution involves some heuristic checks, and
> unwinding (a complex topic).
>
> > Somebody pointed out that on Linux all signal handlers are called from
> > vdso, so I come up with the following code to "inspect" the call frame
> > and see whether there is any address which points at some place inside
> > the VDSO:
>
> This is not true. It is architecture dependent. For examples on how complex
> it is to get this 100% right you have to go read gdb sources to see how
> they do this. It is non-trivial. It might be easier to use a library like
> libunwind to determine this for you (if it even can).


This is a fascinating thread. The downside to using libunwind is that,
iirc, it requires debugging information in the binary to work. In other
words, it would not work on a stripped binary. Please correct me if I am
wrong.

Thanks for the discussion!
Will



>
> --
> Cheers,
> Carlos.
>