 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Chris R" <car### [at] comcast net> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
>
> 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...
That was some good and fast detective work! I was hoping that you would take a
look. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoocom> wrote:
>
> 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.
Ah, I see. I don't know much about the subtle(?) inner code-workings of #local
vs. #declare, but I grasp the idea. I arrived at my 'fix' in my usual way--
trial-and-error guesswork, ha.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
