Bug 849703 - Regular Expression matching in signal handler causes side-effects
Regular Expression matching in signal handler causes side-effects
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Pisar
Fedora Extras Quality Assurance
https://rt.perl.org/rt3/Public/Bug/Di...
: Patch
: 809796 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-20 12:01 EDT by Tim Smith
Modified: 2014-01-02 11:20 EST (History)
13 users (show)

See Also:
Fixed In Version: perl-5.16.3-272.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-02 11:20:55 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch which maintains binary compatiblity (16.36 KB, patch)
2012-10-01 09:25 EDT, Mark Phillips
no flags Details | Diff
Upstream fix ported to 5.16.3 (3.90 KB, patch)
2013-05-10 08:13 EDT, Petr Pisar
no flags Details | Diff

  None (edit)
Description Tim Smith 2012-08-20 12:01:30 EDT
Description of problem:

Executing an RE inside a PERL deferred signal handler causes an unwanted side effect on RE-execution in the code that was being executed when the signal arrived. 

Version-Release number of selected component (if applicable):

"This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi"

How reproducible:

Always

Steps to Reproduce:

Here is a test case:

====== CUT HERE ======
#!/usr/bin/env perl

sub sighup {
    my $bar="This-Has-Dashes-HUP";
    $bar=~s/.*-//;
    print "$bar\n";
    
}

$SIG{'HUP'}=\&sighup;

while (1) {
    my $foo="This:Has:Colons";
    $foo=~s/.*://;
    if ($foo=~m/:/) {
        print "BUG!!: $foo\n";
    }
}
====== CUT HERE ======

Run this endless loop and arrange to send it a SIGHUP once per second.

  
Actual results:

You will see output like the following:

bash$ perl ./t.pl
HUP
HUP
HUP
HUP
BUG!!: This:Has:Colons
HUP
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
HUP
BUG!!: This:Has:Colons
HUP
HUP
HUP
BUG!!: This:Has:Colons


Expected results:

You should get output like this (observed on "This is perl 5, version 12, subversion 4 (v5.12.4) built for x86_64-linux-thread-multi" from Fedora 15):

bash$ perl ./t.pl
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP

Additional info:

This is not a crash, like 809796, though they are very likely related or the same problem.
Comment 1 Petr Pisar 2012-09-26 07:38:08 EDT
Fix in upstream blead branch:

commit b93070ed2e35b0430327cc866a4fcf4042014513
Author: David Mitchell <davem@iabyn.com>
Date:   Tue May 15 12:55:22 2012 +0100

    eliminate PL_reglast(close)?paren, PL_regoffs

breaks ABI <http://permalink.gmane.org/gmane.comp.lang.perl.perl5.porters/115209>.
Comment 2 Mark Phillips 2012-10-01 09:25:19 EDT
Created attachment 619787 [details]
Patch which maintains binary compatiblity
Comment 3 Mark Phillips 2012-10-01 09:25:55 EDT
Unfortunately simply backporting the fix from 5.17 chagelist
b93070ed2e35b0430327cc866a4fcf4042014513 breaks binary compatibility
with plugins.

In particular after re-compiling and installing the Fedora 17 perl RPM
(perl-5.14.2-212.fc17.src.rpm), the automake package started crashing.
The regression tests were all ok.

I have tweaked the back-port to maintain compatibility in three areas (I
am not sure which are important) and now it maintains compatibility and
works with other pre-compiled perl 5.14.2 packages.

The areas I tweaked were:-
1) Modified regcppush/regcppop to push/pop the same values as before the
patch (in particular to still push/pop PL_regoffs, even though it is no
longer used).

2) Modified regcppush/regcppop to have the same prototype as before the
patch, except to make the argument to regcppop non-const. The pop code
writes to both rex and the (unused) PL_* variables.

3) Left the deprecrated PL variables in re_save_state so that the
interpretor object is unchanged - I suspect this is the critical change.

4) The PL_regoffs/PL_reglastparen/PL_reglastcloseparen variables are now
only used by regcppush. I have modified everywere regcppush is called to
set them correctly before regcppush...

I have attached the working patch which appears to pass regression
testing and allows a pre-compiled automake to work when using other
pre-compiled 5.14.2 libs.
Comment 4 Fedora End Of Life 2013-01-16 10:57:43 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Jan Pazdziora 2013-01-16 12:57:26 EST
Issue still present on Fedora 17:

$ rpm -q perl
perl-5.14.3-218.fc17.i686
$ perl
#!/usr/bin/env perl

sub sighup {
    my $bar="This-Has-Dashes-HUP";
    $bar=~s/.*-//;
    print "$bar\n";
    
}

$SIG{'HUP'}=\&sighup;

system("while true ; do kill -HUP $$ ; sleep 1 ; done &");

$SIG{'HUP'}=\&sighup;

while (1) {
    my $foo="This:Has:Colons";
    $foo=~s/.*://;
    if ($foo=~m/:/) {
        print "BUG!!: $foo\n";
    }
}    
__END__
HUP
BUG!!: This:Has:Colons
HUP
HUP
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
HUP
^C
Comment 6 Petr Pisar 2013-05-10 07:14:21 EDT
Upstream has merged promising patch:

commit 47c9d59fcd27684d94480b806b8b6e001aac91cc
Author: Nicholas Clark <nick@ccl4.org>
Date:   Sat Apr 14 15:51:33 2012 +0200

    Remove PERL_ASYNC_CHECK() from Perl_leave_scope().
    
    PERL_ASYNC_CHECK() was added to Perl_leave_scope() as part of commit
    f410a2119920dd04, which moved signal dispatch from the runloop to
    control flow ops, to mitigate nearly all of the speed cost of safe
    signals.
    
    The assumption was that scope exit was a safe place to dispatch signals.
    However, this is not true, as parts of the regex engine call
    leave_scope(), the regex engine stores some state in per-interpreter
    variables, and code called within signal handlers can change these
    values.
    
    Hence remove the call to PERL_ASYNC_CHECK() from Perl_leave_scope(), and
    add it explicitly in the various OPs which were relying on their call to
    leave_scope() to dispatch any pending signals. Also add a
    PERL_ASYNC_CHECK() to the exit of the runloop, which ensures signals
    still dispatch from S_sortcv() and S_sortcv_stacked(), as well as
    addressing one of the concerns in the commit message of
    f410a2119920dd04:
    
        Subtle bugs might remain - there might be constructions that enter
        the runloop (where signals used to be dispatched) but don't contain
        any PERL_ASYNC_CHECK() calls themselves.
    
    Finally, move the PERL_ASYNC_CHECK(); added by that commit to pp_goto to
    the end of the function, to be consistent with the positioning of all
    other PERL_ASYNC_CHECK() calls - at the beginning or end of OP
    functions, hence just before the return to or just after the call from
    the runloop, and hence effectively at the same point as the previous
    location of PERL_ASYNC_CHECK() in the runloop.
Comment 7 Petr Pisar 2013-05-10 08:13:26 EDT
Created attachment 746137 [details]
Upstream fix ported to 5.16.3
Comment 8 Petr Pisar 2013-05-10 08:14:37 EDT
*** Bug 809796 has been marked as a duplicate of this bug. ***
Comment 9 Fedora Update System 2013-05-10 09:07:48 EDT
perl-5.16.3-263.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/perl-5.16.3-263.fc19
Comment 10 Fedora Update System 2013-05-13 03:23:48 EDT
perl-5.16.3-264.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/perl-5.16.3-264.fc19
Comment 11 Fedora Update System 2013-05-26 23:20:50 EDT
perl-5.16.3-264.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 Fedora End Of Life 2013-07-04 03:04:57 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 13 Jan Pazdziora 2013-07-04 03:46:26 EDT
(In reply to Fedora Update System from comment #11)
> perl-5.16.3-264.fc19 has been pushed to the Fedora 19 stable repository.  If
> problems still persist, please make note of it in this bug report.

Nice. With perl-5.16.3-262.fc19.x86_64, I see the problem, with perl-5.16.3-265.fc19.x86_64 it's done. I think you can NEXTRELEASE this bugzilla.
Comment 14 Petr Pisar 2013-07-04 07:47:03 EDT
I want to push the fix into F18 too.
Comment 15 Jan Pazdziora 2013-07-04 07:54:25 EDT
(In reply to Petr Pisar from comment #14)
> I want to push the fix into F18 too.

Ah, good for you. ;-)
Comment 16 Fedora Admin XMLRPC Client 2013-08-12 07:53:00 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 17 Fedora Update System 2013-11-11 08:06:06 EST
perl-5.16.3-245.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/perl-5.16.3-245.fc18
Comment 18 Fedora Update System 2013-11-26 23:33:26 EST
perl-5.16.3-245.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 Fedora End Of Life 2013-12-21 10:40:51 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Note You need to log in before you can comment on or make changes to this bug.