Re: [HACKERS] plperl sigfpe reset can crash the server

2012-09-05 Thread Andres Freund
On Sunday, August 26, 2012 06:10:02 PM Andres Freund wrote:
 On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
  Andres Freund and...@2ndquadrant.com writes:
   Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3
   seems to work. Is that acceptable?
  
  Surely that's breaking perl's expectations, to more or less the same
  degree they're breaking ours?
 
 In the referenced bug they agree that this is the way forward.
As nobody has any better ideas here is a patch doing that:


-- 
Andres Freund   http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services
From c5583861a98c6e5c26961d6346c5b5abc699f90d Mon Sep 17 00:00:00 2001
From: Andres Freund and...@anarazel.de
Date: Wed, 5 Sep 2012 16:04:41 +0200
Subject: [PATCH] Reset SIGFPE handler after plperl initialization

Unfortunately perl resets the sigfpe handler to SIG_IGN which is
bad for two reasons: First, we don't get a nice error message
anymore if a SIGFPE is generated via math on the sql level,
secondly setting SIGFPE to SIG_IGN is strongly discouraged by
posix and invokes undefined behaviour according to it.
At least linux defines this undefined behaviour as resetting the
SIGFPE handler and killing the triggering process.

In perl bug 114574 the perl developers agree that the correct
approach is to just reset the SIGFPE handler.

On some platforms this fixes a server crash with: SELECT (-(2^31))::int/-1;
---
 src/pl/plperl/plperl.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index b31e965..f4b2fa9 100644
--- a/src/pl/plperl/plperl.c
+++ b/src/pl/plperl/plperl.c
@@ -28,6 +28,7 @@
 #include nodes/makefuncs.h
 #include parser/parse_type.h
 #include storage/ipc.h
+#include tcop/tcopprot.h
 #include utils/builtins.h
 #include utils/fmgroids.h
 #include utils/guc.h
@@ -743,6 +744,21 @@ plperl_init_interp(void)
 			perl_sys_init_done = 1;
 			/* quiet warning if PERL_SYS_INIT3 doesn't use the third argument */
 			dummy_env[0] = NULL;
+
+			/*
+			 * Unfortunately perl resets the sigfpe handler to SIG_IGN which is
+			 * bad for two reasons: First, we don't get a nice error message
+			 * anymore if a SIGFPE is generated via math on the sql level,
+			 * secondly setting SIGFPE to SIG_IGN is strongly discouraged by
+			 * posix and invokes undefined behaviour according to it.
+			 * At least linux defines this undefined behaviour as resetting the
+			 * SIGFPE handler and killing the triggering process.
+			 *
+			 * In perl bug 114574 the perl developers agree that the correct
+			 * approach is to just reset the SIGFPE handler.
+			 */
+			pqsignal(SIGFPE, FloatExceptionHandler);
+
 		}
 	}
 #endif
-- 
1.7.10.4


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


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-09-05 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes:
 On Sunday, August 26, 2012 06:10:02 PM Andres Freund wrote:
 On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
 Surely that's breaking perl's expectations, to more or less the same
 degree they're breaking ours?

 In the referenced bug they agree that this is the way forward.

 As nobody has any better ideas here is a patch doing that:

OK.  Do we want to commit this now, or wait till after 9.2.0?
My feeling is it's probably okay to include in 9.2.0, but I can see
that somebody might want to argue not to.  Any objections out there?

regards, tom lane


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


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-09-05 Thread Andres Freund
On Wednesday, September 05, 2012 07:15:52 PM Tom Lane wrote:
 Andres Freund and...@2ndquadrant.com writes:
  On Sunday, August 26, 2012 06:10:02 PM Andres Freund wrote:
  On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
  Surely that's breaking perl's expectations, to more or less the same
  degree they're breaking ours?
  
  In the referenced bug they agree that this is the way forward.
  
  As nobody has any better ideas here is a patch doing that:
 OK.  Do we want to commit this now, or wait till after 9.2.0?
 My feeling is it's probably okay to include in 9.2.0, but I can see
 that somebody might want to argue not to.  Any objections out there?
Perhaps unsurprisingly I would argue for including it. I am not saying its a 
perfect solution, but not bandaiding seems to open a bigger hole/DOS. Given 
that any occurance of SIGFPE inside perl on linux in the last 10 years or so 
would have lead to perl (including postgres w. plperl[u]) getting killed with 
a somewhat distinctive message and the lack of reports I could find about it 
the risk doesn't seem to be too big.

Greetings,

Andres
-- 
 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:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-09-05 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes:
 On Wednesday, September 05, 2012 07:15:52 PM Tom Lane wrote:
 OK.  Do we want to commit this now, or wait till after 9.2.0?
 My feeling is it's probably okay to include in 9.2.0, but I can see
 that somebody might want to argue not to.  Any objections out there?

 Perhaps unsurprisingly I would argue for including it. I am not saying its a 
 perfect solution, but not bandaiding seems to open a bigger hole/DOS. Given 
 that any occurance of SIGFPE inside perl on linux in the last 10 years or so 
 would have lead to perl (including postgres w. plperl[u]) getting killed with
 a somewhat distinctive message and the lack of reports I could find about it 
 the risk doesn't seem to be too big.

Hearing no objections, committed and back-patched.

regards, tom lane


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


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-26 Thread Andres Freund
On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
 Andres Freund and...@2ndquadrant.com writes:
  Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3
  seems to work. Is that acceptable?
 
 Surely that's breaking perl's expectations, to more or less the same
 degree they're breaking ours?
In the referenced bug they agree that this is the way forward.

There is the issue of corrupting the perl environment if you manage to 
generate a SIGFPE - I couldn't so far - but I see no way other than of 
teaching the sigfpe handler to really ignore the error as perl wants.
Not sure if adding such ugliness is acceptable.

The issue that the handler does a longjmp out of external code is a general 
problem btw. While pg will probably never create a sigfpe while in anything 
critical the same cannot be said about external code.
So anything external with persistent state probably can be made to crash or 
similar.

Not sure if there is any real way out of this but making the handler FATAL if 
non pg code is running.

Greetings,

Andres Freund
-- 
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:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-24 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes:
 ./pod/perl581delta.pod:
 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
 programs.

So there's a gap in the restore logic someplace.

 perl.h also has some tidbits: ...
 That doesn't sound very well reasoned and especially not very well tested to 
 me.

Time to file a Perl bug?

regards, tom lane


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


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-24 Thread Andres Freund
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
 Andres Freund and...@2ndquadrant.com writes:
  ./pod/perl581delta.pod:
  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
  programs.
 
 So there's a gap in the restore logic someplace.

Well, the logic is not triggering at all in pg's case. Its just used if perl 
is exec()ing something...


  perl.h also has some tidbits: ...
  That doesn't sound very well reasoned and especially not very well tested
  to me.
 
 Time to file a Perl bug?
Anybody more involved in the perl community volunteering?

Greetings,

Andres
-- 
 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:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-24 Thread Andrew Dunstan


On 08/24/2012 10:58 AM, Andres Freund wrote:

On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:

Andres Freund and...@2ndquadrant.com writes:

./pod/perl581delta.pod:
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
programs.

So there's a gap in the restore logic someplace.

Well, the logic is not triggering at all in pg's case. Its just used if perl
is exec()ing something...



perl.h also has some tidbits: ...
That doesn't sound very well reasoned and especially not very well tested
to me.

Time to file a Perl bug?

Anybody more involved in the perl community volunteering?



Just run perlbug and let us know the bug number.

cheers

andrew




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


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-24 Thread Andres Freund
On Friday, August 24, 2012 05:09:18 PM Andrew Dunstan wrote:
 On 08/24/2012 10:58 AM, Andres Freund wrote:
  On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
  Andres Freund and...@2ndquadrant.com writes:
  ./pod/perl581delta.pod:
  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
  programs.
  
  So there's a gap in the restore logic someplace.
  
  Well, the logic is not triggering at all in pg's case. Its just used if
  perl is exec()ing something...
  
  perl.h also has some tidbits: ...
  That doesn't sound very well reasoned and especially not very well
  tested to me.
  
  Time to file a Perl bug?
  
  Anybody more involved in the perl community volunteering?
 
 Just run perlbug and let us know the bug number.
https://rt.perl.org/rt3/Public/Bug/Display.html?id=114574

Andres
-- 
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:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-24 Thread Andres Freund
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
 Andres Freund and...@2ndquadrant.com writes:
  ./pod/perl581delta.pod:
  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
  programs.
 
 So there's a gap in the restore logic someplace.
 
  perl.h also has some tidbits: ...
  That doesn't sound very well reasoned and especially not very well tested
  to me.
 
 Time to file a Perl bug?
We probably should workaround that bug anyway given that its a pretty trivial 
DOS using only a trusted language and it will take quite some time to push out 
newer perl versions even if that bug gets fixed.

Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3 seems to 
work. Is that acceptable?

Andres
-- 
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:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-24 Thread Alex Hunsaker
On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund and...@2ndquadrant.com wrote:

 We probably should workaround that bug anyway given that its a pretty trivial
 DOS using only a trusted language and it will take quite some time to push out
 newer perl versions even if that bug gets fixed.

 Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3 seems to
 work. Is that acceptable?

Makes sense to me. (I have not looked to see if there is some perl
knob we can flip for this)


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


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-24 Thread Andres Freund
On Saturday, August 25, 2012 12:15:00 AM Alex Hunsaker wrote:
 On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund and...@2ndquadrant.com 
wrote:
  We probably should workaround that bug anyway given that its a pretty
  trivial DOS using only a trusted language and it will take quite some
  time to push out newer perl versions even if that bug gets fixed.
  
  Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3
  seems to work. Is that acceptable?
 
 Makes sense to me. (I have not looked to see if there is some perl
 knob we can flip for this)
I couldn't find any.  After some macro indirection the signal() call ends up 
being done unconditionally by a compiled function (Perl_sys_init3) without any 
conditions, so I don't think there is much that can be done without changing 
perl's source code...

Andres
-- 
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:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-24 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes:
 Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3 seems to
 work. Is that acceptable?

Surely that's breaking perl's expectations, to more or less the same
degree they're breaking ours?

regards, tom lane


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


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-24 Thread Andres Freund
On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
 Andres Freund and...@2ndquadrant.com writes:
  Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3
  seems to work. Is that acceptable?
 
 Surely that's breaking perl's expectations, to more or less the same
 degree they're breaking ours?
Well. Their expectation simply does not work *at all* because they do 
something (setting SIGFPE to SIG_IGN) which is completely ignored on at least 
one major platform (x86 linux) for longer than it has git history.

Their math code seems to work around generating such errors, but I find it 
rather hard to read (or rather read  understand).

Doing what I proposed admittedly has the issue that we would jump out of perl 
code without much ado. I have no idea whats the proper perly way to do so is.
It just seems we should do something...

if (in_perl)
   return;

Would be the equivalent of what they want?

Greetings,

Andres
-- 
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:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-23 Thread Andres Freund
On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
 Hi,
 
 While debugging an instance of this bug I noticed that plperlu always
 removes the SIGFPE handler and sets it to ignore:
 
 
 andres@awork2:~$ psql -p 5435 -U postgres -h /var/run/postgresql test
 Timing is on.
 psql (9.1devel, server 9.1.5)
 Type help for help.
 
 test=# SELECT pg_backend_pid();
  pg_backend_pid
 
9287
 
 root@awork2:/home/andres# grep -E '^Sig(Cgt|Ign)' /proc/9287/status|awk
 '{print $2}'
 01301800
 000180006287
 
 test=# DO LANGUAGE plperlu ;
 
 root@awork2:/home/andres# grep -E '^Sig(Cgt|Ign)' /proc/9287/status|awk
 '{print $2}'
 01301880
 000180006207
 
 Note the 8'th bit being unset in SigCgt and set in SigIgn. Thats SIGFPE...
 
 Not sure how relevant this really is, but it could cause errors to be
 ignored...

In fact it can be used to crash the server:
test=# SELECT (-2^31)::int/-1;
ERROR:  floating-point exception
DETAIL:  An invalid floating-point operation was signaled. This probably means 
an out-of-range result or an invalid operation, such as division by zero.
test=# DO LANGUAGE plperl ;
DO
Time: 172.235 ms
test=# SELECT (-2^31)::int/-1;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Greetings,

Andres
-- 
 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:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-23 Thread Tom Lane
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?

regards, tom lane


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


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-23 Thread Andres Freund
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?

Don't ask me the hard questions at 7 in the morning. I have no clue yet.

I don't see where but something resets SIGFPE before the server crashes. If I 
catch the sigfpe with gdb I see:

test=# SELECT pg_backend_pid();
 pg_backend_pid 

  18084

root@awork2:/home/andres# grep -E '^Sig(Cgt|Ign)' /proc/18084/status
SigIgn: 01301800
SigCgt: 000180006287

test=# SELECT (-2^31)::int/-1;
ERROR:  floating-point exception
DETAIL:  An invalid floating-point operation was signaled. This probably means 
an out-of-range result or an invalid operation, such as division by zero.

root@awork2:/home/andres# grep -E '^Sig(Cgt|Ign)' /proc/18084/status
SigIgn: 01301800
SigCgt: 000180006287

test=# DO LANGUAGE plperl ;

root@awork2:/home/andres# grep -E '^Sig(Cgt|Ign)' /proc/18084/status
SigIgn: 01301880
SigCgt: 000180006207

test=# SELECT (-2^31)::int/-1;

Program received signal SIGFPE, Arithmetic exception.
0x7f858001f8c6 in int4div (fcinfo=0x7f8581b30320)

root@awork2:/home/andres# grep -E '^Sig(Cgt|Ign)' /proc/18084/status
SigIgn: 01301800
SigCgt: 000180006207

Andres
-- 
 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:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-23 Thread Andres Freund
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 ;)

Andres

-- 
 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:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-23 Thread Andres Freund
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:

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_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.
 */
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


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


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-23 Thread Tom Lane
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.

regards, tom lane


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


Re: [HACKERS] plperl sigfpe reset can crash the server

2012-08-23 Thread Andres Freund
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.

./pod/perl581delta.pod:
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
programs.

perl.h also has some tidbits:

/*
 * initialise to avoid floating-point exceptions from overflow, etc
 */
#ifndef PERL_FPU_INIT
#  ifdef HAS_FPSETMASK
#if HAS_FLOATINGPOINT_H
#  include floatingpoint.h
#endif
/* Some operating systems have this as a macro, which in turn expands to a 
comma
   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. 
Hence
   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) 
signal(SIGFPE, SIG_IGN)
#  define PERL_FPU_PRE_EXEC   { Sigsave_t xfpe; rsignal_save(SIGFPE, 
PL_sigfpe_saved, xfpe);
#  define PERL_FPU_POST_EXECrsignal_restore(SIGFPE, xfpe); }
#else
#  define PERL_FPU_INIT

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

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

Andres
-- 
 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:
http://www.postgresql.org/mailpref/pgsql-hackers