On Friday, August 24, 2012 07:19:42 AM Andres Freund wrote:
> On Friday, August 24, 2012 06:55:04 AM Tom Lane wrote:
> > Andres Freund <andres@2ndquadrant.com> writes:
> > > On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
> > >> While debugging an instance of this bug I noticed that plperlu always
> > >
> > >> removes the SIGFPE handler and sets it to ignore:
> > > In fact it can be used to crash the server:
> > Um ... how exactly can that happen, if the signal is now ignored?
>
> My man 2 signal tells me:
> "According to POSIX, the behavior of a process is undefined after it
> ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by
> kill(2) or raise(3)."
>
> Killing the process is a kind of undefined behaviour ;)
And its done explicitly in linux:
In
./arch/x86/kernel/traps.c:
void math_error(struct pt_regs *regs, int error_code, int trapnr)
{
... force_sig_info(SIGFPE, &info, task);
}
and
./kernel/signal.c:* Force a signal that the process can't ignore: if necessary* we unblock the signal and change any
SIG_IGNto SIG_DFL.** Note: If we unblock the signal, we always reset it to SIG_DFL,* since we do not want to have a
signalhandler that was blocked* be invoked when user space had explicitly blocked it.** We don't want to have recursive
SIGSEGV'setc, for example,* that is why we also clear SIGNAL_UNKILLABLE.*/
int
force_sig_info(int sig, struct siginfo *info, struct task_struct *t)
...
Absolutely obvious. Imo sigaction should simply return -1 and set errno to
EINVAL if somebody sets SIGFPE to SIG_IGN then...
Andres
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services