On Sat, Jan 27, 2018 at 02:51:05PM +0000, Dave Mitchell wrote: > On Fri, Jan 26, 2018 at 12:36:12PM -0800, slaven@rezic.de wrote: > > The Geo-StreetAddress-US-1.04 started to segfault while running > > the test suite: > > > > t/01_parser.t (Wstat: 139 Tests: 5 Failed: 0) > > Non-zero wait status: 139 > > It reduces to this: > > my $a = "A"; > my $s = "A"; > $s =~ /$a(?{ $_."X" })/; > > It needs a run-time-compiled pattern with a code block which contains > a multiconcat op. > > I'm looking further into this now. Now fixed with: commit 8327fe931a244c33965f30d2ba4bbe7248016951 Author: David Mitchell <davem@iabyn.com> AuthorDate: Mon Feb 19 21:32:36 2018 +0000 Commit: David Mitchell <davem@iabyn.com> CommitDate: Mon Feb 19 22:06:49 2018 +0000 multiconcat: /$a(?{ $b . "c" })/ could crash RT #132772 Due to the weird order in which codeblocks within patterns are optimised, it was possible for the OP_CONCAT -> OP_MULTICONCAT optimisation to leave freed ops in the op execution chain, leading to assertion failures or crashes. In particular, optimize_optree() needs to always be called before CALL_PEEP(), otherwise the individual subtrees which make up the two children of a concat op may not have the head of subtree as the last op in the subtree's op_next chain: in the subtree RV2SV | GV this subtree gets peephole-optimised to ex-RV2SV | GVSV and GVSV->op_next no longer points to the ex-RV2SV but rather directly to RV2SV->op_next. But S_maybe_multiconcat() assumes that the head of each subtree is the last op to be executed: It updates RV2SV->op_next when reorganising the optree, but leaves GVSV->op_next possibly pointing at a freed op. This commit provides a minimal fix by unconditionally calling optimize_optree() on each code block in Perl_pmruntime(). This may mean that optimize_optree() may be run against the same code block again later, but apart from the slight inefficiency, this should be harmless. A more general fix will be applied post 5.28.0 release. -- Never work with children, animals, or actors.Thread Previous