Thread

Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

Alex Hunsaker <badalex@gmail.com> — 2011-08-08T07:23:08Z

On Sun, Aug 7, 2011 at 17:06, Tim Bunce <Tim.Bunce@pobox.com> wrote:

> On Sat, Aug 06, 2011 at 12:37:28PM -0600, Alex Hunsaker wrote:
>> ...
>> Find attached a version that does the equivalent of local %SIG for
>> each pl/perl(u) call.
>
>> +     gv = gv_fetchpv("SIG", 0, SVt_PVHV);
>> +     save_hash(gv);                  /* local %SIG */
>
> ... [ local %SIG dosn't work ] The %SIG does become empty but the OS
> level handlers, even those installed by perl, *aren't changed*:

Looks like I trusted in $SIG{'ALRM'} being undef after it had been set
in a different scope too much :-( Thanks for pointing this out.

> That sure seems like a bug (I'll check with the perl5-porters list).

Well even if it was deemed a bug, it dont do us any good.

> Localizing an individual element of %SIG works fine.
> In C that's something like this (untested):
>
>    hv = gv_fetchpv("SIG", 0, SVt_PVHV);
>    keysv = ...SV containing "ALRM"...
>    he = hv_fetch_ent(hv, keysv, 0, 0);
>    if (he) {  /* arrange to restore existing elem */
>        save_helem_flags(hv, keysv, &HeVAL(he), SAVEf_SETMAGIC);
>    }
>    else {     /* arrange to delete a new elem */
>        SAVEHDELETE(hv, keysv);
>    }

I played with this a bit... and found yes, it locals them but no it
does not fix the reported problem. After playing with things a bit
more I found even "local $SIG{'ALRM'} = .,..; alarm(1);" still results
in postgres crashing. To wit, local does squat. AFAICT it just resets
the signal handler back to the default with SIG_DFL. (Which in
hindsight I don't know what else I expected it to-do...)

So I think for this to be robust we would have to detect what signals
they set and then reset those back to what postgres wants. Doable, but
is it worth it? Anyone else have any bright ideas?

Find below my test case and attached a patch that locals individual
%SIG elements the way mentioned above.

=> set statement_timeout to '5s';
SET

=> create or replace function test_alarm() returns void as $$ local
$SIG{'ALRM'} = sub { warn "alarm"; }; alarm(1); sleep 2; $$ language
plperlu;
CREATE FUNCTION

=> select test_alarm();
WARNING:  alarm at line 1.
CONTEXT:  PL/Perl function "test_alarm"
 test_alarm
------------

(1 row)

=> select pg_sleep(6);
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.

Server Log:
WARNING:  alarm at line 1.
CONTEXT:  PL/Perl function "test_alarm"
LOG:  server process (PID 32659) was terminated by signal 14: Alarm clock
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process
exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.
FATAL:  the database system is in recovery mode