Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: message received from 54.76.25.247 which
 is an MX secondary for modules-dev@httpd.apache.org)
MIME-Version: 1.0
In-Reply-To: <5535887B.1040708@gmail.com>
References: 
 <CAK_-e8s-Dm-JmBvQ+HAEWVABtD1=j9h-vq8zXeum=Be=RtPnRw@mail.gmail.com>
	<5535887B.1040708@gmail.com>
Date: Fri, 1 May 2015 09:23:10 -0500
Message-ID: 
 <CAK_-e8uSV2EV1FCNhDZXiN=321aMK4BW7nKsjsshGZYaFzLxvw@mail.gmail.com>
Subject: Re: Best practice for handling synchronous signals SIGFPE etc
From: Mark Taylor <mttdgf@gmail.com>
To: modules-dev@httpd.apache.org
Content-Type: multipart/alternative; boundary=001a1133d3d2a43343051505f35c

--001a1133d3d2a43343051505f35c
Content-Type: text/plain; charset=UTF-8

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

--001a1133d3d2a43343051505f35c--