Re: Best practice for handling synchronous signals SIGFPE etc
Great information, thanks all! -Mark On Mon, Apr 20, 2015 at 6:15 PM, Sorin Manolache 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 > > >
Re: Best practice for handling synchronous signals SIGFPE etc
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
Re: Best practice for handling synchronous signals SIGFPE etc
On 04/20/2015 03:50 PM, 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. Does anyone have experience with this? Regards, Mark A hook is provided for a module to perform some processing for coredump-ing signals, but the hook can't be used to prevent httpd from performing the usual sig_coredump work. mod_whatkilledus is a module that uses that particular hook and understands when a request or connection is active. There's info and a download link at http://emptyhammock.com/projects/httpd/diag/index.html
Best practice for handling synchronous signals SIGFPE etc
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. Does anyone have experience with this? Regards, Mark
