On Friday, August 24, 2012 07:33:01 AM Tom Lane wrote:
> Andres Freund <and...@2ndquadrant.com> writes:
> >> 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)."
> So I guess the real question there is: WTF is perl doing setting the
> handling to SIG_IGN?
> Even if you grant the proposition that perl knows what it's doing in
> terms of its internal behavior, which given the above seems doubtful,
> it has no business overriding a host application's signal settings
> like that.

At startup Perl blocks the SIGFPE signal away since there isn't much
Perl can do about it.  Previously this blocking was in effect also for
programs executed from within Perl.  Now Perl restores the original
SIGFPE handling routine, whatever it was, before running external

perl.h also has some tidbits:

 * initialise to avoid floating-point exceptions from overflow, etc
#      include <floatingpoint.h>
#    endif
/* Some operating systems have this as a macro, which in turn expands to a 
   expression, and the last sub-expression is something that gets calculated,
   and then they have the gall to warn that a value computed is not used. 
   cast to void.  */
#    define PERL_FPU_INIT (void)fpsetmask(0)
#  else
#    if defined(SIGFPE) && defined(SIG_IGN) && !defined(PERL_MICRO)
#      define PERL_FPU_INIT       PL_sigfpe_saved = (Sighandler_t) 
#      define PERL_FPU_PRE_EXEC   { Sigsave_t xfpe; rsignal_save(SIGFPE, 
PL_sigfpe_saved, &xfpe);
#      define PERL_FPU_POST_EXEC    rsignal_restore(SIGFPE, &xfpe); }
#    else
#      define PERL_FPU_INIT

#    endif
#  endif
#  define PERL_FPU_PRE_EXEC   {
#  define PERL_FPU_POST_EXEC  }

That doesn't sound very well reasoned and especially not very well tested to 

 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