POV-Ray : Newsgroups : povray.beta-test : Memory corruption in POV-Ray 3.7.1 and UberPOV Server Time
29 Mar 2024 10:05:34 EDT (-0400)
  Memory corruption in POV-Ray 3.7.1 and UberPOV (Message 1 to 5 of 5)  
From: Cousin Ricky
Subject: Memory corruption in POV-Ray 3.7.1 and UberPOV
Date: 28 Sep 2015 17:15:00
Message: <web.5609ad8ba17572e64ed434990@news.povray.org>
I got a memory corruption error trying to render a scene file that uses Ive's
spectral rendering rig.  Here is the message output:

----------[BEGIN MESSAGES]----------
ricky@linux-dc58:~/Documents/POV-Ray/mat/spectral> povray-3.7.1 gold_alloys.pov
+w300 +h270 +a +L../../include-others/SpectralRender
Persistence of Vision(tm) Ray Tracer Version 3.7.1-alpha.8150025.unofficial (g++
 4.8 @ x86_64-suse-linux-gnu)
This is an unofficial version compiled by:
[SNIP]

Parser Options
  Input file: gold_alloys.pov
  Remove bounds........Off
  Split unions.........Off
  Library paths:
    /usr/local/share/povray-3.7
    /usr/local/share/povray-3.7/ini
    /usr/local/share/povray-3.7/include
    /home/ricky/Documents/POV-Ray/include
    /home/ricky/Documents/POV-Ray/include-others
    /home/ricky/Documents/POV-Ray/Object_Collection
    /home/ricky/Documents/POV-Ray/LightsysIV
    /usr/share/fonts/truetype
    ../../include-others/SpectralRender
  Clock value:    0.000  (Animation off)
Image Output Options
  Image resolution.....300 by 270 (rows 1 to 270, columns 1 to 300).
  Output file..........gold_alloys.png, 24 bpp PNG
  Dithering............Off
  Graphic display......On  (gamma: sRGB)
  Mosaic preview.......Off
  Continued trace......Off
Information Output Options
  All Streams to console..........On
  Debug Stream to console.........On
  Fatal Stream to console.........On
  Render Stream to console........On
  Statistics Stream to console....On
  Warning Stream to console.......On
==== [Parsing...] ==========================================================
*** Error in `povray-3.7.1': malloc(): memory corruption: 0x00007f4ef4026740 ***

RGB preview rendering.

-----------[END MESSAGES]-----------

The process hangs at this point.  Not even Ctrl-C (SIGINT) can interrupt it:

----------[BEGIN MESSAGE]----------
^C
uberpov: received signal SIGINT: Interrupt; requested render cancel
^C^C^C^C [ad nauseam]
-----------[END MESSAGE]-----------

The same also happens in UberPOV beta 10.  POV-Ray 3.7.0 renders to completion,
with results as expected.

This is the scene file:

----------[BEGIN CODE]----------
//Preview:
// +w300 +h270 +a
#version 3.7;

#include "spectral.inc"

global_settings
{ assumed_gamma 1
  max_trace_level 100
}

camera
{ location -84 * z
  right x
  up y * 0.9
}

#declare Light = SpectralEmission (E_D65);
#default { finish { diffuse 1 ambient Light * 0.25 } }

box
{ -1, 1 scale <72, 72, 96>
  pigment { C_Average (D_CC_A4, 1, D_CC_B4, 1) }
}

plane
{ -z, 0
  pigment { checker D_CC_F4 C_Average (D_CC_A4, 1, D_CC_B4, 1) }
}
-----------[END CODE]-----------

(Yes, I had not yet gotten to defining a light source.)

POV-Ray 3.7.1-alpha.8150025.unofficial
UberPOV 1.37.1.0-beta.10
(g++ 4.8 @ x86_64-suse-linux-gnu)
openSUSE 13.2 GNU/Linux


Post a reply to this message

From: clipka
Subject: Re: Memory corruption in POV-Ray 3.7.1 and UberPOV
Date: 28 Sep 2015 18:13:07
Message: <5609bb73$1@news.povray.org>
Am 28.09.2015 um 23:13 schrieb Cousin Ricky:
> I got a memory corruption error trying to render a scene file that uses Ive's
> spectral rendering rig.  Here is the message output:
...
> ==== [Parsing...] ==========================================================
> *** Error in `povray-3.7.1': malloc(): memory corruption: 0x00007f4ef4026740 ***

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.


Post a reply to this message

From: Le Forgeron
Subject: Re: Memory corruption in POV-Ray 3.7.1 and UberPOV
Date: 30 Sep 2015 13:55:19
Message: <560c2207$1@news.povray.org>
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)

From: clipka
Subject: Re: Memory corruption in POV-Ray 3.7.1 and UberPOV
Date: 30 Sep 2015 14:37:35
Message: <560c2bef$1@news.povray.org>
Am 30.09.2015 um 19:55 schrieb Le_Forgeron:

> I have kind of good & bad news...
...
> 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).

First of all, thanks for digging this up.

If you feel like going the extra mile and conjuring up a hotfix for
Cousin Ricky, I guess that would be welcome.

As for an official fix for the issue, my suggestion is to leave it be
for now, as I'm currently doing a major overhaul of the splines code
anyway, and this particular piece of code is already scheduled to be
eradicated entirely.


Post a reply to this message

From: Le Forgeron
Subject: Re: Memory corruption in POV-Ray 3.7.1 and UberPOV
Date: 4 Oct 2015 04:13:36
Message: <5610dfb0@news.povray.org>
Le 30/09/2015 20:37, clipka a écrit :
> Am 30.09.2015 um 19:55 schrieb Le_Forgeron:
> 
>> I have kind of good & bad news...
> ...
>> Using valgrind on povray (the scene is fast enough), there is somethin
g
>> fishy in the *new* spline code (no problem of memcheck with older
>> versions, such as the stable version).
> 
> First of all, thanks for digging this up.
> 
> If you feel like going the extra mile and conjuring up a hotfix for
> Cousin Ricky, I guess that would be welcome.
> 
> As for an official fix for the issue, my suggestion is to leave it be
> for now, as I'm currently doing a major overhaul of the splines code
> anyway, and this particular piece of code is already scheduled to be
> eradicated entirely.
> 

Just do not take another decade to finish it :-)

Here a patch for that issue, revising the condition to avoid the out of
bound access (moving from tree to tree2)

As the code is performed only during parse-time, I did not try to
optimize it more than not calling twice the size() function.

--- a/source/core/math/spline.cpp	Fri Sep 18 19:12:10 2015 +0200
+++ b/source/core/math/spline.cpp	Sun Oct 04 10:06:45 2015 +0200
@@ -670,7 +670,26 @@
     /* 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)))
+    bool replace= false;
+    size_t splineSize = sp->SplineEntries.size();// might be needed
more than once, so compute and store
+    if (splineSize) // not empty
+    {
+      if (i==splineSize)
+      {// special case, i would be out of bound
+	if (sp->SplineEntries[i-1].par == p)
+	{
+	  replace = true;
+	}
+      }
+      else
+      {// normal branch, i is inbound
+	if (sp->SplineEntries[i].par == p)
+	{
+	  replace = true;
+	}
+      }
+    }
+    if (replace)
     {
         for(k=0; k<5; k++)
             sp->SplineEntries[i].vec[k] = v[k];


Post a reply to this message


Attachments:
Download 'us-ascii' (2 KB) Download 'tree.dot.png' (30 KB) Download 'tree2.dot.png' (27 KB)

Preview of image 'tree.dot.png'
tree.dot.png

Preview of image 'tree2.dot.png'
tree2.dot.png


 

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.