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

From: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
Subject: Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
Date: 2011-08-08 09:03:55
Message-ID: 20110808090355.GQ2560@timac.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 08, 2011 at 01:23:08AM -0600, Alex Hunsaker wrote:
> On Sun, Aug 7, 2011 at 17:06, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> wrote:
>
> > 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...)

Ah, yes. Hindsight is great. I should have spotted that. Sorry.

> 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?

I'm only considering ALRM. At least that's the only one that seems worth
offering some limited support for. The others fall under "don't do that".

After giving it some more thought it seems reasonable to simply force the
SIGALRM handler back to postgres when a plperlu function returns:

pqsignal(SIGALRM, handle_sig_alarm);

Tim.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-08-08 09:23:41 Re: WIP: Fast GiST index build
Previous Message Anssi Kääriäinen 2011-08-08 08:39:55 Re: Transient plans versus the SPI API