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
invlist_inline.h:40: S__invlist_len: Assertion `((svtype)((invlist)->sv_flags & 0xff)) == SVt_INVLIST' faile #15467
Comments
From @geeknikPerl v5.25.3 (v5.25.2-160-gcd478ec) plus the attached test case cause this assertion failure: invlist_inline.h:40: S__invlist_len: Assertion `((svtype)((invlist)->sv_flags & 0xff)) == SVt_INVLIST' failed |
From @dcollinsnBisects specifically to: 02517e3 is the first new commit regcomp.c: Refactor code dealing with m/[...]/d This consolidates some code that deals with bracketed character classes :100644 100644 2003d3d443759c2a286ad93f304334aad11e3551 a008b1a51bcb1bbdd81c431229367e907bb32581 M regcomp.c Backtrace: (gdb) bt I think the problem is this code, with a sort of use-after-free of nonascii_but_latin1_properties. Changing the order of these blocks resolves /* And add them to the final list of such characters. */ /* Remove them from what now becomes the unconditional list */ Make test is clean. Changing the order shouldn't change the behavior - the subtract modifies posixes, which isn't used in either case of the if block. -- |
From @dcollinsn0001-RT-128686-Fix-a-use-after-free-in-S_regclass.patchFrom 84a5123020f4b392c0d3f3dc2ea46f5bbdcb0526 Mon Sep 17 00:00:00 2001
From: Dan Collins <dcollinsn@gmail.com>
Date: Thu, 21 Jul 2016 00:02:58 -0400
Subject: [PATCH] [RT #128686] Fix a use-after-free in S_regclass
---
regcomp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/regcomp.c b/regcomp.c
index 7f6d5ee..738a21a 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -17474,6 +17474,10 @@ S_regclass(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth,
_invlist_intersection(posixes, PL_UpperLatin1,
&nonascii_but_latin1_properties);
+ /* Remove them from what now becomes the unconditional list */
+ _invlist_subtract(posixes, nonascii_but_latin1_properties,
+ &posixes);
+
/* And add them to the final list of such characters. */
if (has_upper_latin1_only_utf8_matches) {
_invlist_union(has_upper_latin1_only_utf8_matches,
@@ -17486,10 +17490,6 @@ S_regclass(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth,
= nonascii_but_latin1_properties;
}
- /* Remove them from what now becomes the unconditional list */
- _invlist_subtract(posixes, nonascii_but_latin1_properties,
- &posixes);
-
/* And the remainder are the unconditional ones */
if (cp_list) {
_invlist_union(cp_list, posixes, &cp_list);
--
2.8.1
|
From [Unknown Contact. See original ticket]Bisects specifically to: 02517e3 is the first new commit regcomp.c: Refactor code dealing with m/[...]/d This consolidates some code that deals with bracketed character classes :100644 100644 2003d3d443759c2a286ad93f304334aad11e3551 a008b1a51bcb1bbdd81c431229367e907bb32581 M regcomp.c Backtrace: (gdb) bt I think the problem is this code, with a sort of use-after-free of nonascii_but_latin1_properties. Changing the order of these blocks resolves /* And add them to the final list of such characters. */ /* Remove them from what now becomes the unconditional list */ Make test is clean. Changing the order shouldn't change the behavior - the subtract modifies posixes, which isn't used in either case of the if block. -- |
From @khwilliamsonThanks for finding this. I freed a variable before its final use |
The RT System itself - Status changed from 'new' to 'open' |
@khwilliamson - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#128686 (status was 'resolved')
Searchable as RT128686$
The text was updated successfully, but these errors were encountered: