develooper Front page | perl.perl5.porters | Postings from February 2018

Re: [perl #132772] Blead Breaks CPAN:TIMB/Geo-StreetAddress-US-1.04.tar.gz

Thread Previous
Dave Mitchell
February 20, 2018 09:32
Re: [perl #132772] Blead Breaks CPAN:TIMB/Geo-StreetAddress-US-1.04.tar.gz
Message ID:
On Sat, Jan 27, 2018 at 02:51:05PM +0000, Dave Mitchell wrote:
> On Fri, Jan 26, 2018 at 12:36:12PM -0800, 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 <>
AuthorDate: Mon Feb 19 21:32:36 2018 +0000
Commit:     David Mitchell <>
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
    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
    this subtree gets peephole-optimised to
    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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About