Coredump in Perl_re_intuit_start #16871
Comments
From @dur-randirCreated by @dur-randirWhile fuzzing perl v5.29.8-21-gde59f38ed9 built with afl and run eval q!//,caller grep/b\x{1c0}ss0/i,caller 0! GDB stack trace is following: #0 0x000055555588917d in Perl_re_intuit_start (rx=0x555555b411b0, This is a regression between 5.26 and 5.28, bisect points to commit 141513f regcomp.c: Under/i segregate folding vs non-folding characters For matching sequences of characters, the regex compiler generates Perl Info |
From @khwilliamsonThis is failing in a part of the engine I don't know anything about. I think the blamed commit is a red herring, probably it just perturbs things so that this showed up, but there is an underlying bug. The attached patch intercepts this and avoids the failure, but I don't believe it's the correct thing to do. I'm hoping someone more familiar with the engine could look at it, if only to give me hints as to how to proceed. The commit message gives further details |
From @khwilliamson0004-work-around-for-perl-133892.patchFrom 142137083d6c79a4415cfe0b411a1a4a12099123 Mon Sep 17 00:00:00 2001
From: Karl Williamson <khw@cpan.org>
Date: Fri, 22 Mar 2019 22:25:09 -0600
Subject: [PATCH 4/4] work around for [perl #133892]
The problem here is that the data structure 'other' contains a
'utf8_substr' but not a plain 'substr'. But utf8_target is false, so
'must' is pointing to NULL, and the assertion fails.
This patch adds a test for 'must' being NUL, and abandons the match.
But I don't know what the real solution should be. How did we get here
with a UTF-8 substr, but the target isn't?
---
regexec.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/regexec.c b/regexec.c
index 00e822d729..da1613bfa6 100644
--- a/regexec.c
+++ b/regexec.c
@@ -1270,6 +1270,12 @@ Perl_re_intuit_start(pTHX_
s = other_last;
must = utf8_target ? other->utf8_substr : other->substr;
+ if (! must) {
+ DEBUG_EXECUTE_r(Perl_re_printf( aTHX_
+ " no other substr in valid UTF8ness; giving up...\n"));
+ goto fail_finish;
+ }
+
assert(SvPOK(must));
{
char *from = s;
--
2.17.1
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @hvdsOn Fri, 22 Mar 2019 21:38:03 -0700, khw wrote:
Minimal reproducer is something like: We're coming from regexec.c:1533 /* Contradict one of substrings */ via I think the check at 1176 could handle this, and bail if there's It might be better to simplify a lot of this - test up front if either It's also slightly odd that this does not happen with a single match; Hugo commit f67366c [perl #133892] coredump in Perl_re_intuit_start Make sure we have a valid non-utf8 'other' check substring before we Inline Patchdiff --git a/regexec.c b/regexec.c
index 9d67da6..ad589e2 100644
--- a/regexec.c
+++ b/regexec.c
@@ -1173,8 +1173,8 @@ Perl_re_intuit_start(pTHX_
/* now look for the 'other' substring if defined */
- if (utf8_target ? prog->substrs->data[other_ix].utf8_substr
- : prog->substrs->data[other_ix].substr)
+ if (prog->substrs->data[other_ix].utf8_substr
+ || prog->substrs->data[other_ix].substr)
{
/* Take into account the "other" substring. */
char *last, *last1;
@@ -1184,6 +1184,11 @@ Perl_re_intuit_start(pTHX_
do_other_substr:
other = &prog->substrs->data[other_ix];
+ if (!utf8_target && !other->substr) {
+ if (!to_byte_substr(prog)) {
+ NON_UTF8_TARGET_BUT_UTF8_REQUIRED(fail);
+ }
+ }
/* if "other" is anchored:
* we've previously found a floating substr starting at check_at. |
From @hvdsOn Mon, 25 Mar 2019 04:50:48 -0700, hv wrote:
Now pushed with test as fd8def1. Hugo |
|
@hvds - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release today of Perl 5.30.0, this and 160 other issues have been Perl 5.30.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
From @nwc10On Wed, 27 Mar 2019 06:18:49 -0700, hv wrote:
Thanks Sergey for finding this, and to Karl and Hugu for figuring out the fix. I've just hit this SEGV when testing stuff at work with v5.28.1. It's a SEGV at the same location (for the same reason) but despite gdb showing a short regex and a short target string, I wasn't able to get a small testcase out of it (or I think even have it reliably crash), so it's good to see that (1) I don't have to and (2) it's already fixed. My only "problem" now is whether our internal build system is up to installing custom patches, or whether I can sell my boss on v5.30.0 Nicholas Clark |
Migrated from rt.perl.org#133892 (status was 'resolved')
Searchable as RT133892$
The text was updated successfully, but these errors were encountered: