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