Re: Setting signal handlers considered unsafe?

With perl 5.8.8 on CentOS 5.2, exposure of SIG_DFL has something to do with setting a local $SIG{ALRM}.

#!/opt/perl/bin/perl
use strict;
use warnings;

print "set handler 1\n";
$SIG{ALRM} = sub { print "handler 1\n"; };
print "set handler 2\n";
$SIG{ALRM} = sub { print "handler 2\n"; };
print "set handler 3 (local)\n";
{
        local $SIG{ALRM} = sub { print "handler 3\n"; };
}
[download]

produces the following strace output:

write(1, "set handler 1\n", 14set handler 1
)         = 14
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {0x80a3330, [], 0}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(1, "set handler 2\n", 14set handler 2
)         = 14
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {0x80a3330, [], 0}, {0x80a3330, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(1, "set handler 3 (local)\n", 22set handler 3 (local)
) = 22
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, {0x80a3330, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {0x80a3330, [], 0}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {0x80a3330, [], 0}, {0x80a3330, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(0)                           = ?
[download]

Update: It is localizing $SIG{ALRM} that sets the signal handler to SIG_DFL. Presumably a side effect of $SIG{ALRM} being set to undef when it is localized.

#!/opt/perl/bin/perl
use strict;
use warnings;
use Data::Dumper;

print "set handler 1\n";
$SIG{ALRM} = sub { print "handler 1\n"; };
print "set handler 2\n";
$SIG{ALRM} = sub { print "handler 2\n"; };
print "set handler 3 (local)\n";
{
        local $SIG{ALRM};
        print "\$SIG{ALRM} is now local: " . Dumper($SIG{ALRM});
        $SIG{ALRM} = sub { print "handler 3\n"; };
        print "\$SIG{ALRM} is now set locally: " . Dumper($SIG{ALRM});
}
[download]

produces:

write(1, "set handler 1\n", 14set handler 1
)         = 14
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {0x80a3330, [], 0}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(1, "set handler 2\n", 14set handler 2
)         = 14
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {0x80a3330, [], 0}, {0x80a3330, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(1, "set handler 3 (local)\n", 22set handler 3 (local)
) = 22
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, {0x80a3330, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(1, "$SIG{ALRM} is now local: $VAR1 ="..., 37$SIG{ALRM} is now lo
+cal: $VAR1 = '';
) = 37
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {0x80a3330, [], 0}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(1, "$SIG{ALRM} is now set locally: $"..., 56$SIG{ALRM} is now se
+t locally: $VAR1 = sub { "DUMMY" };
) = 56
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {0x80a3330, [], 0}, {0x80a3330, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(0)                           = ?
[download]

Comment on Re: Setting signal handlers considered unsafe? Select or Download Code

Replies are listed 'Best First'.
Re^2: Setting signal handlers considered unsafe? by gone2015 (Deacon) on Nov 06, 2008 at 13:54 UTC
It is localizing `$SIG{ALRM}` that sets the signal handler to `SIG_DFL`. Presumably a side effect of `$SIG{ALRM}` being set to undef when it is localized. That is stunningly unfriendly. Particularly as localisation is suggested in the documentation (perlipc). Looks like a bug to me... or at least in need of a serious (additional) caveat in the documentation ?	[reply] [d/l] [select]
Re^3: Setting signal handlers considered unsafe? by ikegami (Patriarch) on Nov 09, 2008 at 18:07 UTC
It's not a side-effect. It's not a bug. `local` undefines its argument. Details	[reply] [d/l]
Re^4: Setting signal handlers considered unsafe? by gone2015 (Deacon) on Nov 09, 2008 at 19:34 UTC
It's not a side-effect. It's not a bug. local undefines its argument. The documentation Temporary Values via local() says: .... The argument list may be assigned to if desired, which allows you to initialize your local variables. (If no initializer is given for a particular variable, it is created with an undefined value.) This does not say that the lvalues in the `local` argument list will be set `undef` and later the result of any initialiser will be assigned to it. Taking the empirical approach: `use strict ; use warnings ; our $fred = 78 ; { local $fred = $fred ? 'Was Defined' : 'undef' ; print "\$fred = $fred\n" ; } ; print "\$fred = $fred\n" ;` [download] gives: $fred = Was Defined $fred = 78 which reenforces the feeling that the variable being localised retains its old value up to the moment the new value is set. Were it not for the side effect of setting `$SIG{ALRM}` to `undef`, nobody would ever be able to tell that being set `undef` is apparently a step in the initialisation of the local. The implementation may assume it doesn't matter -- we live and learn ! IMO, this quacks like a bug.	[reply] [d/l] [select]
Re^5: Setting signal handlers considered unsafe? by ikegami (Patriarch) on Nov 09, 2008 at 20:03 UTC
Re^6: Setting signal handlers considered unsafe? by gone2015 (Deacon) on Nov 10, 2008 at 00:06 UTC
Some notes below your chosen depth have not been shown here
Re^2: Setting signal handlers considered unsafe? by gone2015 (Deacon) on Nov 09, 2008 at 16:59 UTC
I'm pleased to see that you have reported this as a bug: #60360: local $SIG{FOO} = sub {...}; sets signal handler to SIG_DFL Looking at the `strace` output: rt_sigprocmask(SIG_BLOCK, ALRM, [], 8) = 0 rt_sigaction(SIGALRM, {SIG_DFL}, {0x80a3330, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 it appears that the `SIG_BLOCK` call of `rt_sigprocmask` is storing the mask state, and that the `SIG_SETMASK` call is restoring that -- certainly that's what one would hope for ! While one waits for a fix, the work-around seems to be to wrap `local $SIG{FOO} = ...` in a `SIG_BLOCK`/`SIG_SETMASK` pair -- as suggested by brother gnosek in 721812, above: `use POSIX qw(:signal_h) ; my $sigset = POSIX::SigSet->new ; my $blockset = POSIX::SigSet->new( SIGALRM ) ; sigprocmask(SIG_BLOCK, $blockset, $sigset ); local $SIG{ALRM} = sub .... ; sigprocmask(SIG_SETMASK, $sigset );` [download] The code below tests with and without the extra masking. With the extra masking I haven't seen it fail. Without the extra masking it fails almost instantly with a "TWIDDLE" of 1, but seems to last longer for larger "TWIDDLE". What I find remarkable is how quickly this fails when the extra masking is disabled. `SIG_DFL` is set only briefly. On the assumption that the `ALRM` signals are essentially random wrt the main process, I'd expect the time to fail to be more or less related to the time that `SIG_DFL` is set. I may be underestimating how long the various system calls take, compared to the small amount of Perl code. Or there may be some part of the system calls causing some synchronisation between the processes, or a greater likelihood of collecting an ALRM at the `SIG_SETMASK` call... The `$TWIDDLE` argument increases the time spent with the "temporary" `ALRM` handler set. Increasing that value does appear to increase how long it takes before the `SIG_DFL` handler is invoked (in the absense of the extra masking) and the program comes to a sudden `Alarm clock` halt. I have not seen the error: Unable to create sub named "" at .... reported in 721812, but brother gnosek is running 5.8.8 while I am running 5.10.0. I wonder if it's to do with creating a very large number of anonymous subroutines ? Read more... See the code (1303 Bytes)	[reply] [d/l] [select]
Re^3: Setting signal handlers considered unsafe? by ig (Vicar) on Nov 11, 2008 at 11:19 UTC
I'm pleased to see that you have reported this as a bug: If perl were new, I might argue that local should not set variables when localizing (to undef or anything else and regardless of whether there is an initializer), as initializers are available to set the value and including this feature in local precludes not changing the value. But perl is not new and changing local now would no doubt be problematic. After reading the further posts in this thread, I am inclined to the view that the design of local is less than ideal but that the only bug is in the documentation. In which case I guess I should submit a patch to the docs to go along with my bug report. I am thinking perlsub and perlipc should probably both be changed. Are there other sections that need attention? Maybe what is needed is a new operator, very much like local except that it does not change the value of the variable. It's description in perlsub would be exactly as for local except for the definition of what happens if there is no initializer, which might read as follows for the new operator: If no initializer is given for a particular variable its value is not changed if it already exists or, if it does not already exist, its value is set to undef. This would leave local as is, so no existing scripts would be broken, and it would provide a new means of managing signal handlers, and anything else where setting the variable to undef, even briefly, is undesirable. But this wouldn't be a bug, this would be a feature request. Update: just as I was about to submit patches to perlsub and perlipc, I received notice that a patch has been applied that skips setting undef if there is an initializer. I hope it doesn't upset anyone and get taken out. Read more... (3 kB)	[reply] [d/l]