-
Notifications
You must be signed in to change notification settings - Fork 561
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
panic: regcomp.c: 13346: negative offset: -68719492257 #16977
Comments
From @dur-randirCreated by @dur-randirWhile fuzzing perl v5.29.9-63-g2496d8f3f7 built with afl and run /0000000000000000[\N{U+0.00}0000/ to emit 'panic: regcomp.c: 13346: negative offset: -68719492257 trying Perl Info
|
From @dur-randirI was finally able to bisect this to d62e749 is the first bad commit regcomp.c: Add ability to not warn during substitute parse Under certain conditions, regcomp.c will pretend something other than This commit adds and uses a mechanism to turn off warnings while parsing The stand-alone reproducer also turned out to be much more elaborate: eval q!m'000000000000000000[0\N{U+00.0}0'!; warn GDB stacktrace to the panic() point is: #1 0x00007ffff7c25535 in __GI_abort () at abort.c:79 |
From @jkeenanOn Fri, 26 Apr 2019 17:01:14 GMT, randir wrote:
Sergey, could you post how you bisected this? Did you use Porting/bisect.pl? If so, could you post the full command you used to get the result? If you didn't use Porting/bisect.pl, could you post what you did use? If there's some special magic here, I think we should add it to our documentation. Thank you very much. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 4/23/19 8:33 AM, Sergey Aleynikov (via RT) wrote:
This is fixed by the attached patch |
From @khwilliamson0001-PATCH-perl-134059-panic-outputting-a-warning.patchFrom 7f08dd4d0989eee2b2ed9af3e525206ba5632414 Mon Sep 17 00:00:00 2001
From: Karl Williamson <khw@cpan.org>
Date: Mon, 29 Apr 2019 15:24:18 -0600
Subject: [PATCH] PATCH: [perl #134059] panic outputting a warning
This was due to a logic error on my part. We need to save and restore a
value. Instead, it was getting restored to the wrong value.
This particular instance of the bug was outputting a fatal error
message, so that the only harm is not giving the user the correct info,
and creating unnecessary work for them and us when it gets reported.
But this bug could manifest itself when trying to output just a warning
that the program otherwise would carry on from.
---
regcomp.c | 12 ++++++++++--
t/re/reg_mesg.t | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/regcomp.c b/regcomp.c
index fbd5c1809a..5029fba48e 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -131,6 +131,8 @@ struct RExC_state_t {
char *parse; /* Input-scan pointer. */
char *copy_start; /* start of copy of input within
constructed parse string */
+ char *save_copy_start; /* Provides one level of saving
+ and restoring 'copy_start' */
char *copy_start_in_input; /* Position in input string
corresponding to copy_start */
SSize_t whilem_seen; /* number of WHILEM in this expr */
@@ -229,6 +231,7 @@ struct RExC_state_t {
#define RExC_precomp (pRExC_state->precomp)
#define RExC_copy_start_in_input (pRExC_state->copy_start_in_input)
#define RExC_copy_start_in_constructed (pRExC_state->copy_start)
+#define RExC_save_copy_start_in_constructed (pRExC_state->save_copy_start)
#define RExC_precomp_end (pRExC_state->precomp_end)
#define RExC_rx_sv (pRExC_state->rx_sv)
#define RExC_rx (pRExC_state->rx)
@@ -821,8 +824,13 @@ static const scan_data_t zero_scan_data = {
} STMT_END
/* Setting this to NULL is a signal to not output warnings */
-#define TURN_OFF_WARNINGS_IN_SUBSTITUTE_PARSE RExC_copy_start_in_constructed = NULL
-#define RESTORE_WARNINGS RExC_copy_start_in_constructed = RExC_precomp
+#define TURN_OFF_WARNINGS_IN_SUBSTITUTE_PARSE \
+ STMT_START { \
+ RExC_save_copy_start_in_constructed = RExC_copy_start_in_constructed;\
+ RExC_copy_start_in_constructed = NULL; \
+ } STMT_END
+#define RESTORE_WARNINGS \
+ RExC_copy_start_in_constructed = RExC_save_copy_start_in_constructed
/* Since a warning can be generated multiple times as the input is reparsed, we
* output it the first time we come to that point in the parse, but suppress it
diff --git a/t/re/reg_mesg.t b/t/re/reg_mesg.t
index c5c79f0323..d10fa2c09a 100644
--- a/t/re/reg_mesg.t
+++ b/t/re/reg_mesg.t
@@ -318,6 +318,7 @@ my @death =
'/\p{Is_Other_Alphabetic=F}/ ' => 'Can\'t find Unicode property definition "Is_Other_Alphabetic=F" {#} m/\p{Is_Other_Alphabetic=F}{#}/',
'/\x{100}(?(/' => 'Unknown switch condition (?(...)) {#} m/\\x{100}(?({#}/', # [perl #133896]
'/(?[\N{KEYCAP DIGIT NINE}/' => '\N{} in inverted character class or as a range end-point is restricted to one character {#} m/(?[\\N{U+39.FE0F.20E3{#}}/', # [perl #133988]
+ '/0000000000000000[\N{U+0.00}0000/' => 'Unmatched [ {#} m/0000000000000000[{#}\N{U+0.00}0000/', # [perl #134059]
);
# These are messages that are death under 'use re "strict"', and may or may
--
2.17.1
|
From @dur-randirOn Mon, 29 Apr 2019 15:45:44 -0700, jkeenan wrote:
Difficulties that I encounter with bisecting come mostly from how I generate all those test cases - the binary fuzzed is actually a modified perl. I've started with light modifications, but now they're more and more deep, so when I have a failing test case, it can "resist" bisecting in a number of ways, including: - it just doesn't fail on non-modified perl, which can either be an error in modifications, or those modifications add something that is required for the reproduction (for ex., a text eval block) So, there's no magic, just knowledge of how are those test cases generated and what can affect them. |
From @khwilliamsonFixed by commit cc16d26 PATCH: [perl #134059] panic outputting a warning |
@khwilliamson - Status changed from 'open' to 'pending release' |
Migrated from rt.perl.org#134059 (status was 'pending release')
Searchable as RT134059$
The text was updated successfully, but these errors were encountered: