On Aug 4, 2011, at 5:25 PM, Alvaro Herrera wrote:
> Excerpts from Hannu Krosing's message of jue ago 04 09:53:40 -0400 2011:
>> On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote:
>>>
>>> On 08/04/2011 09:07 AM, Hannu Krosing wrote:
>
>>>> I have been helping some people to debug a SIGALARM related crash
>>>> induced by using pl/perlu http get functionality
>>>>
>>>> I have been so far able to repeat the crash only on Debian 64 bit
>>>> computers. DB create script and instructions for reproducing the crash
>>>> attached
>>>>
>>>> The crash is related to something leaving begind a bad SIGALARM handler,
>>>> as it can be (kind of) fixed by resetting sigalarm to nothing using perl
>>>> function
>>>
>>> So doesn't this look like a bug in the perl module that sets the signal
>>> handler and doesn't restore it?
>
> I vaguely remember looking in the guts of LWP::UserAgent a few years ago
> and being rather annoyed at the way it dealt with sigalrm -- it
> interfered with other uses we had for the signal. I think we had to run
> a patched version of that module or something, not sure.
>
>>> What happens if you wrap the calls to the module like this?:
>>>
>>> {
>>> local $SIG{ALRM};
>>> # do LWP stuff here
>>> }
>>> return 'OK';
>>>
>>>
>>> That should restore the old handler on exit from the block.
>>>
>>
>> Sure, but how expensive would it be for pl/perl to do this
>> automatically ?
>
> Probably too much, but then since this is an untrusted pl my guess is
> that it's OK to request the user to do it only in functions that need
> it. I wonder if we could have a check on return from a function that
> the sighandler is still what we had before the function was called, to
> help discover this problem.
If we can do that, than why won't we move a step further and restore an old
signal handler on mismatch?
--
Command Prompt, Inc. http://www.CommandPrompt.com
PostgreSQL Replication, Consulting, Custom Development, 24x7 support