Front page | perl.perl5.porters |
Postings from July 2013
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