Re: BUG? die() executing outside scope of eval block

I believe the problem occurs when a SIGALRM and SIGCHLD occur very close together. The SIGALRM causes the program to exit the eval block's scope with the die("ALRM EVENT\n").

Could it be the other way around? I see that you're switching off the alarm outside of the eval. Maybe you should switch off the alarm inside the SIGCHLD handler:

-local $SIG{'CHLD'} = sub { die("CHLD EVENT\n"); };
+local $SIG{'CHLD'} = sub { alarm(0); die("CHLD EVENT\n"); };
[download]

Another approach would be to return to using unsafe signal handlers inside the eval, see POSIX's sigaction() for that.

Liz

Update:
Actually, Perl 5.8.1 introduced a new idiom for temporarily allowing unsafe signals:

local $ENV{PERL_SIGNALS} = 'unsafe';
[download]

From perl581delta.pod:

Unsafe signals again available

In Perl 5.8.0 the so-called "safe signals" were introduced. This means that Perl no longer handles signals immediately but instead "between opcodes", when it is safe to do so. The earlier immediate handling easily could corrupt the internal state of Perl, resulting in mysteri- ous crashes.

However, the new safer model has its problems too. Because now an opcode, a basic unit of Perl execution, is never interrupted but instead let to run to completion, certain operations that can take a long time now really do take a long time. For example, certain network operations have their own blocking and timeout mechanisms, and being able to interrupt them immediately would be nice.

Therefore perl 5.8.1 introduces a "backdoor" to restore the pre-5.8.0 (pre-5.7.3, really) signal behaviour. Just set the environment vari- able PERL_SIGNALS to "unsafe", and the old immediate (and unsafe) sig- nal handling behaviour returns. See "PERL_SIGNALS" in perlrun and "Deferred Signals (Safe Signals)" in perlipc.

In completely unrelated news, you can now use safe signals with POSIX::SigAction. See "POSIX::SigAction" in POSIX.

Comment on Re: BUG? die() executing outside scope of eval block Select or Download Code

Replies are listed 'Best First'.
Re: Re: BUG? die() executing outside scope of eval block by jdhedden (Deacon) on Dec 19, 2003 at 13:25 UTC
Using unsafe signals sounds like a step backwards. Besides, why would that even work? The 'bug' is that there is a vulnerable gap between the end of the eval block's scope and the restoration of the %SIG hash. This vulnerability exists whether or not you're using safe or unsafe signals. The alarm(0) in the CHLD handler is a good idea, but this doesn't relate at all to the second scenario I presented (parent->SIGUSR1->child). So while it might be a workaround for the first case, it is not a general solution. I think the key issue is illustrated by this phrase: Perl no longer handles signals immediately but instead "between opcodes", when it is safe to do so. While this sounds good, it still does not say whether or not this 'bug' exists. If one opcode is the end of the eval block, and the next opcode is to start restoring %SIG, but a signal occurs in between them, then that is a bug. It is not enough to suppress signal handling between opcodes. Perl needs to go further and ensure safe signal handling when the %SIG hash modified inside an eval block. But again, my original request still exists. Would someone familiar with the Perl interpreter's code please verify what I am saying. Is there a 'gap' between the end of an eval block and the restoration of the %SIG hash such that an incoming signal could result in execution of the (now defunct) local signal handler that was inside the eval block?	[reply]

Replies are listed 'Best First'.

Re: Re: BUG? die() executing outside scope of eval block
by jdhedden (Deacon) on Dec 19, 2003 at 13:25 UTC

The alarm(0) in the CHLD handler is a good idea, but this doesn't relate at all to the second scenario I presented (parent->SIGUSR1->child). So while it might be a workaround for the first case, it is not a general solution.

I think the key issue is illustrated by this phrase:
Perl no longer handles signals immediately but instead "between opcodes", when it is safe to do so.
While this sounds good, it still does not say whether or not this 'bug' exists. If one opcode is the end of the eval block, and the next opcode is to start restoring %SIG, but a signal occurs in between them, then that is a bug. It is not enough to suppress signal handling between opcodes. Perl needs to go further and ensure safe signal handling when the %SIG hash modified inside an eval block.

But again, my original request still exists. Would someone familiar with the Perl interpreter's code please verify what I am saying. Is there a 'gap' between the end of an eval block and the restoration of the %SIG hash such that an incoming signal could result in execution of the (now defunct) local signal handler that was inside the eval block?

[reply]