develooper Front page | perl.perl5.porters | Postings from July 2013

Re: Perl 5.18 and Regexp::Grammars

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
July 1, 2013 10:13
Subject:
Re: Perl 5.18 and Regexp::Grammars
Message ID:
20130701101218.GA2063@iabyn.com
On Thu, Jun 27, 2013 at 10:42:54PM -0600, Karl Williamson wrote:
> On 06/27/2013 06:22 PM, Dave Mitchell wrote:
> >I can reduce the failure to the following code:
> >
> >     m{(?&foo){0}(?<foo>)}
> >
> >which SEGVs during compilation. 'git blame' blames Karl.
> >(which is not to say that there aren't other SEGing issues, which might
> >involve code blocks, but this first SEGV is innocent of them).
> >
> >Karl, is this something you can deal with?
> >
> >v5.17.7.0-60-g3018b82
> >
> >3018b823898645e44b8c37c70ac5c6302b031381 is the first bad commit
> >commit 3018b823898645e44b8c37c70ac5c6302b031381
> 
> I believe I have found the problem.  I mistakenly combined what
> should have been two commits in this one, and the commit message
> doesn't even mention the one at fault.
> 
> What appears to be going on is that
> 
> (?&foo){0}
> 
> is getting replaced by a NOTHING node, which is an optimization we
> agreed to on p5p.  Thus it doesn't set up 'foo', and so the
> reference to it is NULL, which segfaults when dereferenced.
> 
> Suggestions as to how to proceed are welcome.  Obviously, we could
> remove the optimization.  Or apply it when what is being replaced is
> one of certain node types, or has some characteristic, like width.
> I haven't looked into this at all.

Not knowing the details of the optimisation, I would hazard the suggestion
what we just remove the optimisation for now (hopefully a simple fix that
can be done now and backported in time for 5.18.1), then worry about doing
a better fix later on.

-- 
Standards (n). Battle insignia or tribal totems.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About