[perl #28961] unsafe signals

On Mon Apr 19 08:51:15 2004, powerman@sky.net.ua wrote:
> This example will hang (it should deliver SIGUSR1 and die "OK").
> 
> It will work as expected if some delay will be added in chield
> process before kill(), for example:
> 
> unless ($chield_pid) { sleep 1; kill 10, $parent_pid; exit };
> 
> Also it will work as expected without adding this delay if
> safe signals will be used:
> 
> $sigaction->safe(1);
> 
> ---cut---
> use POSIX;
> 
> $sigaction = POSIX::SigAction->new(sub {die "OK\n"});
> $sigaction->safe(0);
> sigaction(10, $sigaction);
> 
> my $parent_pid = $$;
> die "can't fork\n" unless defined(my $chield_pid = fork());
> unless ($chield_pid) { kill 10, $parent_pid; exit };
> 
> sleep 2;
> print "Exit !!!\n";
> ---cut---
> 
> BTW, where I can found list of async-signal safe perl functions?
> For example, is sysread() safe?

Calling the handler isn't async-signal safe in the first place (nothing
that may allocate memory is), so does it matter if any builtin you call
in it is safe? There's a limited number of circumstances in which it is
safe, and I don't think core has any way of triggering any of them.

More than that, dieing is more than just async-signal unsafe, it's so
verboten CERT has an explicit advisory against the C construct (longjmp)
that's used to implement it: [SIG32-C], on top of the one that advices
against async-signal unsafe.

I can reproduce this issue on a CentOS 5 machine (using 5.8.8 and 5.16),
but not on my own Ubuntu machine (5.14 and 5.16). It would seems the
platform has become more tolerant of this undefined condition, but it
has every right to hang (or format your hard-drive). I'd suggest closing
this as "wontfix".

Leon


SIG32-C:
https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+longjmp%28%29+from+inside+a+signal+handler

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=28961

• [perl #28961] unsafe signals by Leon Timmermans via RT
• [perl #28961] unsafe signals by James E Keenan via RT
• [perl #28961] unsafe signals by James E Keenan via RT
• [perl #28961] unsafe signals by Jesse Luehrs via RT