Re: SIGFPE handler is naive
От
Tom Lane
Тема
Re: SIGFPE handler is naive
Дата
Msg-id
13981.1344980809@sss.pgh.pa.us
Ответ на
Re: SIGFPE handler is naive (Noah Misch)
Список
Дерево обсуждения
SIGFPE handler is naive Robert Haas <robertmhaas@gmail.com>
Re: SIGFPE handler is naive Noah Misch <noah@leadboat.com>
Re: SIGFPE handler is naive Robert Haas <robertmhaas@gmail.com>
Re: SIGFPE handler is naive Tom Lane <tgl@sss.pgh.pa.us>
Re: SIGFPE handler is naive "ktm@rice.edu" <ktm@rice.edu>
Re: SIGFPE handler is naive Robert Haas <robertmhaas@gmail.com>
Re: SIGFPE handler is naive Robert Haas <robertmhaas@gmail.com>
Re: SIGFPE handler is naive Noah Misch <noah@leadboat.com>
Re: SIGFPE handler is naive Tom Lane <tgl@sss.pgh.pa.us>
Re: SIGFPE handler is naive Nils Goroll <slink@schokola.de>
Re: SIGFPE handler is naive Greg Stark <stark@mit.edu>
Re: SIGFPE handler is naive Robert Haas <robertmhaas@gmail.com>
Re: SIGFPE handler is naive Noah Misch <noah@leadboat.com>
Re: SIGFPE handler is naive Tom Lane <tgl@sss.pgh.pa.us>
Re: SIGFPE handler is naive Robert Haas <robertmhaas@gmail.com>
Noah Misch 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 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 ID of 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 по дате отправления