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

On Thu, Aug 4, 2011 at 09:11, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>> What *I'd* like is a way to prevent libperl from touching the host
>> application's signal handlers at all.  Sadly, Perl does not actually
>> think of itself as an embedded library, and therefore thinks it owns all
>> resources of the process and can diddle them without anybody's
>> permission.
>>
>>
>
> I'm not sure how perl (or any loadable library) could restrict that in
> loaded C code, which many perl modules call directly or indirectly. It's as
> open as, say, a loadable C function is in Postgres ;-) You have a gun. It's
> loaded. If you point it at your foot and pull the trigger don't blame us. I
> think you just need to be very careful about what you do with plperlu. Don't
> be surprised if things break.

Well we can't prevent perl XS (aka C) from messing with signals (and
other modules like POSIX that expose things like sigprocmask,
siglongjump etc.) , but we could prevent plperl(u) from playing with
signals on the perl level ala %SIG.

[ IIRC I proposed doing something about this when we were talking
about the whole Safe mess, but I think there was too much other
discussion going on at the time :-) ]

Mainly the options im thinking about are:
1) if anyone touches %SIG die
2) turn %SIG into a regular hash so people can set/play with %SIG, but
it has no real effect.
3) local %SIG before we call their trigger function. This lets signals
still work while "in trigger scope" (like we do for %_TD)
4) if we can't get any of the above to work we can save each %SIG
handler before and restore them after each trigger call. (mod_perl
does something similar so Im fairly certain we should be able to get
that to work)

Thoughts?