I have been experiencing crashes running the latest beta of POV-Ray v3.8 (Win64)
when trying to call a spline.  The narrowed it down to a few lines of code that
causes the crash:

#macro make_spline()
    #local _s   = spline {
        quadratic_spline
        0, <0, 0, 0>,
        1, <0, 0, 1>,
        2, <1, 0, 2>,
        3, <2, 1, 3>
    }
    _s
#end

#local myspline = spline { make_spline() }

#debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")

The contents of the spline don't seem to matter nor does the type of spline.
The result is a memory access violation.

When I run the same code on v3.7 it works fine.

Declaring the spline outside of a macro does not cause the crash:

#local myspline   = spline {
    natural_spline
    0, <0, 0, 0>,
    1, <0, 0, 1>,
    2, <1, 0, 2>,
    3, <2, 1, 3>
}

#debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")

-- Chris R.

Post a reply to this message

"Chris R" <car### [at] comcastnet> wrote:
> I have been experiencing crashes running the latest beta of POV-Ray v3.8 (Win64)
> when trying to call a spline.  The narrowed it down to a few lines of code that
> causes the crash:
>
> #macro make_spline()
>     #local _s   = spline {
>         quadratic_spline
>         0, <0, 0, 0>,
>         1, <0, 0, 1>,
>         2, <1, 0, 2>,
>         3, <2, 1, 3>
>     }
>     _s
> #end
>
> #local myspline = spline { make_spline() }
>
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")
>
> The contents of the spline don't seem to matter nor does the type of spline.
> The result is a memory access violation.
>
> When I run the same code on v3.7 it works fine.
>
> Declaring the spline outside of a macro does not cause the crash:
>
> #local myspline   = spline {
>     natural_spline
>     0, <0, 0, 0>,
>     1, <0, 0, 1>,
>     2, <1, 0, 2>,
>     3, <2, 1, 3>
> }
>
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")
>
> -- Chris R.

One last observation, the following code also seems to work fine.  This leads me
to believe the problem lies with returning the spline identifier from the macro
and then trying to use it.  It's a kludgy work-around, but I can use it to
continue on my current project.

#macro make_spline_macro()
#declare myspline = spline {
   natural_spline
   0, <0, 0, 0>,
   1, <0, 0, 1>,
   2, <1, 0, 2>,
   3, <2, 1, 3>
}
#end

make_spline_macro()

#debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")


-- Chris R.

Post a reply to this message

hi,

"Chris R" <car### [at] comcastnet> wrote:
> I have been experiencing crashes running the latest beta of POV-Ray v3.8 (Win64)
> when trying to call a spline.  The narrowed it down to a few lines of code that
> causes the crash:
>
> #macro make_spline()
>     #local _s   = spline {
>         quadratic_spline
>         0, <0, 0, 0>,
>         1, <0, 0, 1>,
>         2, <1, 0, 2>,
>         3, <2, 1, 3>
>     }
>     _s
> #end
>
> #local myspline = spline { make_spline() }
>
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")
>
> The contents of the spline don't seem to matter nor does the type of spline.
> The result is a memory access violation.

my self compiled beta.2 (Linux) too crashes, same error I think.  the
alpha.9945627 outputs the 'pt_' ok.

changing the macro to

#macro make_spline()
    spline {
        quadratic_spline
        0, <0, 0, 0>,
        1, <0, 0, 1>,
        2, <1, 0, 2>,
        3, <2, 1, 3>
    }
#end

gives me 'Parse Error: Spline must have at least one entry.', and no crash.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ...
> changing the macro to
>
> #macro make_spline()
>     spline {
>         quadratic_spline
>         0, <0, 0, 0>,
>         1, <0, 0, 1>,
>         2, <1, 0, 2>,
>         3, <2, 1, 3>
>     }
> #end
>

and then writing

#declare myspline = make_spline();

appears to work, though.


regards, jr.

Post a reply to this message

"Chris R" <car### [at] comcastnet> wrote:
> ..narrowed it down to a few lines of code that
> causes the crash:
>
> #macro make_spline()
>     #local _s   = spline {
>         quadratic_spline
>         0, <0, 0, 0>,
>         1, <0, 0, 1>,
>         2, <1, 0, 2>,
>         3, <2, 1, 3>
>     }
>     _s
> #end
>

I find that the above by itself runs OK in Windows 10, no fatal error. (I'm
running v3.8.0 beta 1, but I don't expect beta 2 to be much different.)

However, adding your #debug line causes the memory access violation.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I find that the above by itself runs OK in Windows 10, no fatal error.

Sorry, I meant to include your #local myspline too. The following still runs OK.

#macro make_spline()
    #local _s   = spline {
        quadratic_spline
        0, <0, 0, 0>,
        1, <0, 0, 1>,
        2, <1, 0, 2>,
        3, <2, 1, 3>
    }
    _s
#end

#local myspline = spline { make_spline() }
>
> However, adding your #debug line causes the memory access violation.

Post a reply to this message

On 2023-02-08 10:54 (-4), Chris R wrote:
> "Chris R" <car### [at] comcastnet> wrote:
>> I have been experiencing crashes running the latest beta of POV-Ray v3.8 (Win64)
>> when trying to call a spline.  The narrowed it down to a few lines of code that
>> causes the crash:
>>
>> [snip]

Confirmed on GNU/Linux.  V3.8 beta 2 yields a seg fault.  All other
versions I have beyond 3.1.0.10, including the master branch, UberPOV,
and the discontinued v3.7.1-RC1, yield "std::bad_alloc".  My oldest
UberPOV is 1.37.1.0-b10.

> One last observation, the following code also seems to work fine.  This leads me
> to believe the problem lies with returning the spline identifier from the macro
> and then trying to use it.  It's a kludgy work-around, but I can use it to
> continue on my current project.
> 
> #macro make_spline_macro()
> #declare myspline = spline {
>    natural_spline
>    0, <0, 0, 0>,
>    1, <0, 0, 1>,
>    2, <1, 0, 2>,
>    3, <2, 1, 3>
> }
> #end
> 
> make_spline_macro()
> 
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")

This non-kludgy workaround also works:

#macro make_spline()
    spline {
        quadratic_spline
        0, <0, 0, 0>,
        1, <0, 0, 1>,
        2, <1, 0, 2>,
        3, <2, 1, 3>
    }
#end

#local myspline = make_spline()

#debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")

Post a reply to this message

Just discovered that your full original code example (WITH #debug) works OK, if
the #local inside the macro is changed to #declare. Why that should matter, I
don't know.

#macro make_spline()
    #declare _s   = spline {
        quadratic_spline
        0, <0, 0, 0>,
        1, <0, 0, 1>,
        2, <1, 0, 2>,
        3, <2, 1, 3>
    }
    _s
#end

#local myspline = spline { make_spline() }

#debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")

Post a reply to this message

On 2/9/23 05:02, Kenneth wrote:
> Just discovered that your full original code example (WITH #debug) works OK, if
> the #local inside the macro is changed to #declare. Why that should matter, I
> don't know.
> 
> #macro make_spline()
>      #declare _s   = spline {
>          quadratic_spline
>          0, <0, 0, 0>,
>          1, <0, 0, 1>,
>          2, <1, 0, 2>,
>          3, <2, 1, 3>
>      }
>      _s
> #end
> 
> #local myspline = spline { make_spline() }
> 
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")
> 

The debugging you all have done has been helpful to me. Thanks!

Short on time but, I think we are seeing two different failure 
mechanisms, the second being tangled in the fix for Ingo's spline issue 
from July 2021. Ref:

http://news.povray.org/povray.beta-test/thread/%3CXnsAD687938A665Aseed7%40news.povray.org%3E/

Message: <XnsAD687938A665Aseed7@news.povray.org>

Running my povr branch with the final form of the fix using a clone 
method suggested by Christoph over my original code, I get the 
segmentation fault seen by many of you in newer official POV-Ray code. I 
have traced the segfault to this bit in parser_expressions.cpp:


     if (!New)
     {
         if (Old)
         {
             // Note. v3.7/v3.8 was always: New = new LinearSpline(*Old);
             New = Old->Clone(); // <-- Segfault with Clone method.

If I revert to the previous & incorrect code of:

           New = new LinearSpline(*Old);

I then see:

Parse Error:
std::bad_array_new_length

which is perhaps a different signature for the same bug, but I've not 
had time to dig into it.

Also not looked yet at the v3.7 stable code. The parser changed somewhat 
significantly after v3.7 as many know.

What I suspect off the top of my head is more recent parser code is 
dumping the macro defined #local spline where it should not. The first 
question is why and have a thought or two(a).

(a) For example, wondering about the new macro caching mechanism and 
whether it makes the macro 'look' like it's in another ram file with 
respect to #local ID / spline content persistence.

Bill P.

Post a reply to this message

On 2/9/23 06:02, Kenneth wrote:
> Just discovered that your full original code example (WITH #debug) works OK, if
> the #local inside the macro is changed to #declare. Why that should matter, I
> don't know.

A #local has to be declared in a temporary location, then released when
the macro returns.  This is opportunity for an allocation/de-allocation
mix-up that doesn't occur with #declare.

Post a reply to this message