crash caused by $_ conflict in signal handler

[iddq]

Description
program exits on readline from stdin after sighandler executed

Steps to Reproduce
https://github.com/iddq/perlbug-sighandler/blob/main/sigtest.pl
uname > /tmp/test.txt
./sigtest.pl
killall -USR1 sigtest.pl

Expected behavior
sigtest.pl should not terminate

Perl configuration
Summary of my perl5 (revision 5 version 28 subversion 1) configuration:

Platform:
osname=linux
osvers=4.9.0
archname=x86_64-linux-gnu-thread-multi
uname='linux localhost 4.9.0 #1 smp debian 4.9.0 x86_64 gnulinux '

[Grinnz]

I cannot reproduce the "crash", but it is known that while-readline clobbers $_ and anything aliased to it, and you should either localize $_ when using it or (ideally) avoid implicit assignment to $_ at all, with while (my $line = <$fh>).

[Leont]

I can totally see how this could crash if $_ gets reallocated in the signal handler while readline is operating on raw pointers on the inside of its buffer. There might even already be a bugreport about this.

[Grinnz]

I have reproduced the issue.

The main loop of the program waits on input from STDIN, and upon receiving a newline (or EOF) it assigns that line to $_, and the while loop then tests if $_ is defined in order to continue.

If SIGUSR1 has been received, the inner while-readline has clobbered $_ while the program is waiting on input, and ultimately sets $_ to undef as the inner while-readline concludes. When the outer while-readline then receives input, it terminates (normally, not a crash) as if $_ was undefined, even though the new input should have overwritten what $_ was set to. I suspect it would be because it ran the signal handler while this statement was running.

[Grinnz]

This can be more simply reproduced with:

#!/usr/bin/env perl

use strict;
use warnings;

$SIG{'USR1'}  = sub { warn "Got SIGUSR1\n"; undef $_ };

my $i;
while(<STDIN>) {
  print $i++, "\n";
}

[tonycoz]

If there's no crash then it's not a bug. If a signal handler modifies a variable then that change is visible in the interrupted code.

There was an issue (see 368ac47 for the fix) and might be more issues where perl's internal state is corrupted by code mishandling a signal handler, but this doesn't appear to be that.

[Grinnz]

There is still a bug though there is no crash, in that $_ does not get assigned the new line before the while loop decides to end - the signal handler occurs while waiting on readline, distinctly before the assignment.

[iddq]

Sometimes I got Out of memory error when I discovered this bug.

[tonycoz]

There is still a bug though there is no crash, in that $_ does not get assigned the new line before the while loop decides to end - the signal handler occurs while waiting on readline, distinctly before the assignment.

The implicit assignment for while(<...>) doesn't generate a separate assignment op, instead readline() itself does the assignment incrementally as it reads the line in, so in this case $_ is modified while readline() is in the middle of modifying $_.

I can see a couple of ways to fix it

• remove the optimization, so while (<FOO>) actually expands to the expected ops - this means everyone using this construct pays for it
• make the optimization runtime dependent on whether a signal handler has been set (via %SIG), so that readline() works with a temporary, only assigning to $_ on completion - this means we'll need to test both cases

but I'm not sure it's worth fixing.