Front page | perl.perl5.porters |
Postings from June 2013
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.
Thread Previous
|
Thread Next