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 <and...@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:


void math_error(struct pt_regs *regs, int error_code, int trapnr)
        force_sig_info(SIGFPE, &info, task);


 * Force a signal that the process can't ignore: if necessary
 * we unblock the signal and change any SIG_IGN to SIG_DFL.
 * Note: If we unblock the signal, we always reset it to SIG_DFL,
 * since we do not want to have a signal handler that was blocked
 * be invoked when user space had explicitly blocked it.
 * We don't want to have recursive SIGSEGV's etc, for example,
 * that is why we also clear SIGNAL_UNKILLABLE.
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 Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to