Le 29/09/2015 00:13, clipka a écrit :
> Am 28.09.2015 um 23:13 schrieb Cousin Ricky:
>> I got a memory corruption error trying to render a scene file that use
s Ive's
>> spectral rendering rig.  Here is the message output:
> ...
>> ==== [Parsing...] ===============
=========================
==================
>> *** Error in `povray-3.7.1': malloc(): memory corruption: 0x00007f4ef4
026740 ***
> 
> Damn.
> 
> Thanks for pointing this out, but this may be more than non-trivial to
> track down; so anything you could do to narrow down the search would be

> greatly appreciated.
> 

I have kind of good & bad news...
with the stable version, no problem.
with the master version, problem.
with hgpovray (my version with bonus), no problem.
with my master, problem.

my master is kind of late behind official master, and hgpovray is even
more late, so it might be in some updated code, but not so fresh code.
(and when I speak of official master, that already an older than latest
version, so far POV-Ray 3.7.1-alpha.8032017.unofficial )

The compiler does not seems to affect the issue.

debugger give mkfree (backend/math/splines.cpp: 440) as the detection of
the problem.

se.resize(se.size()+1);

But that might be irrelevant, as it's a memory corruption that got
detected, and corruption might have been done previously.

Using valgrind on povray (the scene is fast enough), there is something
fishy in the *new* spline code (no problem of memcheck with older
versions, such as the stable version).

Invalid read of size 8

   /* If p is already in spline, replace */
    /* The clause after the || is needed because findt returns
sp->SplineEntries.size()
     * if p is greater than OR EQUAL TO the highest par in the spline */
    if(!sp->SplineEntries.empty() && ((sp->SplineEntries[i].par == p)
 ||
(i == sp->SplineEntries.size() && sp->SplineEntries[i-1].par == p
)))

(circa 664 in spline.cpp ).

Out of bound read access, when i is SplineEntries.size().
Beware of side effect of [] operator when SplineEntries is something
like a map. For vector (the type of SplineEntries), it is an undefined
behavior.

IMHO, that code should be rebalanced, to either benefit from evaluation
shortcut (but that need heavy comments and it's dangerous) or to avoid
such out of bound access.

With such code in place, when out of luck, the Insert_Spline_Entry is
going to smash the bytes behind the end of the vector with the new
values (5 components-povray-vector). Random value in for [i].par just
need to match p and the corruption is done.

Post a reply to this message

Attachments:
Download 'memcheck4.txt' (14 KB)