Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
От | Alexey Klyukin |
---|---|
Тема | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |
Дата | |
Msg-id | D5BB6482-A1F9-4576-A7D2-264DBF4C04B3@commandprompt.com обсуждение исходный текст |
Ответ на | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: