httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Taylor <mtt...@gmail.com>
Subject Re: Best practice for handling synchronous signals SIGFPE etc
Date Fri, 01 May 2015 14:23:10 GMT
Great information, thanks all!

-Mark

On Mon, Apr 20, 2015 at 6:15 PM, Sorin Manolache <sorinm@gmail.com> wrote:

> On 2015-04-20 21:50, Mark Taylor wrote:
>
>> I found that ./server/mpm_unix.c is registering a handler (sig_coredump)
>> for SIGFPE, SIGSEGV, and other synchronous signals.  I'd like to handle at
>> least these two in my module, using my own handler.  But then how do I
>> determine if the the handler is called on a request thread or a server
>> thread? And I'd like to default to still run the sig_coredump() function
>> if
>> it's signal is not in my module.
>>
>>
> Have a look at the man-page of sigaction and getcontext. When you set a
> signal handler you get the old signal handler (3rd argument of sigaction).
> So you can store it in a variable. In your own signal handler you do want
> you intend to do and at the end you call the old signal handler. In this
> way you can call sig_coredump. However you have to make sure that you set
> your signal handler _after_ apache has set his. Otherwise apache will
> replace yours.
>
> Have a look at the siginfo_t structure that is passed by the OS to your
> handler. You can get the program ID and the user ID from that structure.
> But not the thread apparently. Anyway, at least you can determine if the
> signal was raised in the parent or one of the worker children.
>
> Look also at the ucontext structure (man getcontext) that is passed to
> your signal handler. Maybe you can determine the source of the signal from
> that structure, though I think it's too close to machine code and registers
> to be useful.
>
> Alternately, you could use a thread-local variable (
> https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Thread-Local.html). The first
> thing you do when you enter each function of your module is to set the
> variable. Whenever you exit a function you reset it. Thus, you may
> determine in your signal handler by inspection of the variable if the
> signal was raised by your module. (This works only if the signal handler is
> executed in the thread where the signal was raised which is not always the
> case. Otherwise you'll set some variable in your thread and read another
> one in the handler. Here's some information:
> http://stackoverflow.com/questions/11679568/signal-handling-with-multiple-threads-in-linux.
> Apparently the handlers for SIGSEGV and SIGFPE are called in the thread
> that raised them but it's not clear.)
>
> Sorin
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message