New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Safe signals mean that regexps can't be interrupted #10220
Comments
From @nwc10As of (I think) perl 5.8.0, we're using "safe signals", where the actual C This has the side effect that alarm signals can no longer be used to interrupt Something like this will run "forever": $ time ./perl -we '$SIG{ALRM} = sub {die "Timeout"}; alarm 3; $_ = "a" x 1000 . "b" x 1000 . "c" x 1000; /.*a.*b.*c.*d.*/;' It seems that a viable solution to this is to dispatch signals at convenient My assumption is that "forever" regexps are only slow because they backtrack Inline Patchdiff --git a/regexec.c b/regexec.c
index 17a0dc6..bca2e65 100644
--- a/regexec.c
+++ b/regexec.c
@@ -5521,6 +5521,7 @@ no_silent:
yes_state = st->u.yes.prev_yes_state;
state_num = st->resume_state + 1; /* failure = success + 1 */
+ PERL_ASYNC_CHECK();
goto reenter_switch;
}
result = 0;
$ time ./perl -we '$SIG{ALRM} = sub {die "Timeout"}; alarm 3; $_ = "a" x 1000 . "b" x 1000 . "c" x 1000; /.*a.*b.*c.*d.*/;' real 0m3.002s All tests pass, and (it happens that) perlbench can't spot a difference. Nicholas Clark |
From @nwc10On Tue, Mar 09, 2010 at 07:30:54AM -0800, Nicholas Clark wrote:
Ben Morrow (correctly) observes that this would mean that signal handlers
Need more tests :-) Nicholas Clark |
From @iabynOn Wed, Mar 10, 2010 at 10:35:01AM +0000, Nicholas Clark wrote:
Hopefully making regexes fully re-entrant will be something I'll get a -- |
The RT System itself - Status changed from 'new' to 'open' |
From @nwc10On Wed, Mar 10, 2010 at 12:07:28PM +0000, Dave Mitchell wrote:
I'd recommend North Cyprus (as I often do in the office). We don't have an Nicholas Clark |
From talby@trap.mtview.ca.usThis is a bug report for perl from talby@trap.mtview.ca.us, Signal handling appears to be delayed during the processing of some I originally discovered my problem in perl v5.8.8, but have reproduced I have a sample which seems like it should prevent the regex from #!/usr/bin/perl Flags: Site configuration information for perl 5.10.0: Configured by Debian Project at Thu Oct 1 22:38:45 UTC 2009. Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Locally applied patches: @INC for perl 5.10.0: Environment for perl 5.10.0: |
From @schwerntalby@trap.mtview.ca.us (via RT) wrote:
Thank you for your report. This is likely a consequence of "safe signals" Safe signals can be disabled by setting the PERL_SIGNALS environment variable Please read -- |
The RT System itself - Status changed from 'new' to 'open' |
From talby@trap.mtview.ca.usYour explanation fits everything I've observed. Thanks very much for Michael G Schwern via RT wrote:
|
From @cpansproutOn Wed Mar 10 02:35:58 2010, nicholas wrote:
But the regexp engine has been made reëntrant now, by commit 9133212. Does that mean your patch will work now, or does it still need a bit of |
From @doyNicholas, any thoughts on this? It seems pretty straightforward, but I'm |
From @nwc10On Mon, Jul 02, 2012 at 05:13:28PM -0700, Jesse Luehrs via RT wrote:
I'm not sufficiently familiar with what *really* needs saving in the regex Also, not sure if the advice about North Cyprus is still valid, for practical Nicholas Clark |
From @demerphqOn 3 July 2012 at 15:25, Nicholas Clark <nick@ccl4.org> wrote:
As far as I know we are properly re-entrant now, so I think I will Yves -- |
From @dcollinsnOn Tue Mar 15 12:56:55 2016, demerphq wrote:
It appears that Yves applied this patch in 8df928d. Is there any more to be done? -- |
Migrated from rt.perl.org#73464 (status was 'open')
Searchable as RT73464$
The text was updated successfully, but these errors were encountered: