Re: SIGFPE handler is naive - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SIGFPE handler is naive
Date
Msg-id 13981.1344980809@sss.pgh.pa.us
Whole thread Raw
In response to Re: SIGFPE handler is naive  (Noah Misch <noah@leadboat.com>)
Responses Re: SIGFPE handler is naive
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Tue, Aug 14, 2012 at 08:40:06AM -0400, Robert Haas wrote:
>> On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark <stark@mit.edu> wrote:
>>> It is possible to check if the signal was synchronous or was sent from
>>> an external process. You can check siginfo->si_pid to see who sent you
>>> the signal. I'm not sure checking that and handling it at
>>> check_for_interrupts if it's asynchronous is the best solution or not
>>> though.

>> If that's portable it might be an option, but I doubt that it is.

> I suspect it is portable.

Single Unix Spec V2 says (on the sigaction man page)
The si_code member contains a code identifying the cause of thesignal. If the value of si_code is less than or equal to
0,then thesignal was generated by a process and si_pid and si_uid respectivelyindicate the process ID and the real user
IDof the sender.
 

I'm not sure I would trust checking si_pid alone; it would definitely
fail on my old HPUX box, where I see that field is union'ed with si_addr
and so will read as garbage for a locally-sourced SIGFPE.  But it might
be that checking si_code alone would work reliably.

I think that rejecting an externally sourced SIGFPE might be worth doing
if we can distinguish that reliably.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: GetSnapshotData() comments
Next
From: Peter Eisentraut
Date:
Subject: Re: -Wformat-zero-length