Great information, thanks all! -Mark
On Mon, Apr 20, 2015 at 6:15 PM, Sorin Manolache <sor...@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 > > >
