Re: [HACKERS] plperl sigfpe reset can crash the server
Andres Freund 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
On Wednesday, September 05, 2012 07:15:52 PM Tom Lane wrote: > Andres Freund 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
Andres Freund 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
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 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 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
On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote: > Andres Freund 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
On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote: > Andres Freund 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
Andres Freund 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
On Saturday, August 25, 2012 12:15:00 AM Alex Hunsaker wrote: > On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund 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
On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund 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
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote: > Andres Freund 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
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 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
On 08/24/2012 10:58 AM, Andres Freund wrote: On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote: Andres Freund 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
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote: > Andres Freund 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
Andres Freund 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
On Friday, August 24, 2012 07:33:01 AM Tom Lane wrote:
> Andres Freund 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
#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
Re: [HACKERS] plperl sigfpe reset can crash the server
Andres Freund 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
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 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
On Friday, August 24, 2012 06:55:04 AM Tom Lane wrote: > Andres Freund 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
On Friday, August 24, 2012 06:55:04 AM Tom Lane wrote: > Andres Freund 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
Andres Freund 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
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
