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

[Yubin Ruan <ablacktshirt at gmail dot com>]

Hi Carlos,

2017-10-19 10:19 GMT+08:00 Carlos O'Donell <carlos@redhat.com>:
> On 10/18/2017 06:52 PM, Yubin Ruan wrote:
>> 2017-10-19 2:34 GMT+08:00 Carlos O'Donell <carlos@redhat.com>:
>>> 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).

So I think I am going to talk with some gdb people some more.

>> 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).

Will it be better if we can limit the architecture to X86/64?

Yubin