httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sorin Manolache <>
Subject Re: Best practice for handling synchronous signals SIGFPE etc
Date Mon, 20 Apr 2015 23:15:07 GMT
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 
( 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:

Apparently the handlers for SIGSEGV and SIGFPE are called in the thread 
that raised them but it's not clear.)


View raw message