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

On 08/04/2011 08:44 PM, Alex Hunsaker wrote:
> On Thu, Aug 4, 2011 at 17:52, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alex Hunsaker<badalex(at)gmail(dot)com> writes:
>>> On Thu, Aug 4, 2011 at 16:34, David E. Wheeler<david(at)kineticode(dot)com> wrote:
>>>> On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote:
>>>>> 3) local %SIG before we call their trigger function. This lets signals
>>>>> still work while "in trigger scope" (like we do for %_TD)
>>>> +1
>>> That seems to be what most people up-thread thought as well. I dont
>>> see it being too expensive. Ill see if I can whip something up today.
>> The scenario I was imagining was:
>> [ $SIG{ALRM} + statement timeout-- what happens?]
>> ....
>> Even if you don't think statement_timeout is a particularly critical
>> piece of functionality, similar interference with the delivery of, say,
>> SIGUSR1 would be catastrophic.
> Yipes, I see your point.
>
>> How do you propose to prevent this sort of problem?
> Well, I think that makes it unworkable.
>
> So back to #1 or #2.
>
> For plperlu sounds like we are going to need to disallow setting _any_
> signals (minus __DIE__ and __WARN__). I should be able to make it so
> when you try it gives you a warning something along the lines of
> "plperl can't set signal handlers, ignoring...".
>
> For plperl I think we should probably do the same. It seems like
> Andrew might disagree though? Anyone else want to chime in on if
> plperl lets you muck with signal handlers?
>
> Im not entirely sure how much of this is workable, I still need to go
> through perl's guts and see. At the very worst I think we can mark
> each signal handler that is exposed in %SIG readonly (which would mean
> we would die instead of warning), but I think I can make the warning
> variant workable as well.
>
> I also have not dug deep enough to know how to handle __WARN__ and
> __DIE__ (and exactly what limitations allowing those will impose). I
> still have some work at $day_job before I can really dig into this.

Let's slow down a bit. Nobody that we know of has encountered the
problem Tom's referring to, over all the years plperlu has been
available. The changes you're proposing have the potential to downgrade
the usefulness of plperlu considerably without fixing anything that's
known to be an actual problem. Instead of fixing a problem caused by
using LWP you could well make LWP totally unusable from plperlu.

And it still won't do a thing about signal handlers installed by C code.

And plperlu would be the tip of the iceberg. What about all the other
PLs, not to mention non-PL loadable modules?

But we *can* fix the original problem reported, namely failure to
restore signal handlers on function exit, with very little downside
(assuming it's shown to be fairly cheap).

cheers

andrew