The pigment object causes a crash when the object is a CSG construction.

Below are two scenes that allmost always crashes with type 1, 2 or 11
error (Macintosh)

Anyone having the same problems? Any fixes?

//First scene
camera {
    location <0.0, 0.0, -6>
    angle 60
    look_at <0.0, 0.0, 0.0>
}

light_source {
    <0.0, 20, -100>
    rgb <1.0, 1.0, 1.0>
}


#declare TexObj =
        // Point connector macro
    #macro P_C_P ( Center, Radius, R, G, B, F, T, Center2,  Radius2,
R2, G2, B2, F2, T2)
        #local dx = Center2.x - Center.x ;      #if (dx=0) #declare dx=
0.000001; #end
        #local dy = Center2.y - Center.y ;
        #local dz = Center2.z - Center.z ;
        #local len = sqrt (dx*dx+dy*dy+dz*dz);
        #local xylen = sqrt (dx*dx+dy*dy);
        #local D = acos( (Radius-Radius2)/len);
            < cos(D)*Radius, 0, 0>, sin(D)*Radius ,
            < len + (cos(D)*Radius2), 0, 0>, sin(D)*Radius2
        texture {
            pigment {
                gradient x
                color_map { [ 0.0 1.0 rgbft < R, G, B, F, T > color
rgbft < R2, G2, B2, F2, T2 > ] }
                scale <( len + (cos(D)*Radius2))-(cos(D)*Radius), 1, 1>
                translate < cos(D)*Radius, 0, 0>
            }
        }
        rotate <0,  degrees(-atan2(dz, xylen)), degrees(atan2 (dy, dx))>
        translate <Center.x, Center.y, Center.z>
    #end

    #declare C = 0;
    #declare Copies = 500;
    
    #declare S1 = -1;   
            union {
        #while ( C < Copies)
            #declare Center = <0, 0, 0>;   #declare Radius = 1.0;
            #declare Center2 = <0, 0, 0>;   #declare Radius2 = 1.0;
            sphere {

                #if (((C/(250)) - floor (C/(250))) = 0)     #declare
SubC1 = 0;  #declare S1 = S1 * -1;#end  //reverse
                #declare Radius = Radius * (0.01 #if (S1<0) + ((0.1
-(0.01))/(250) * (250)) #end + (((SubC1 * (0.1 -(0.01))/(250 -1))) * S1
));
                #if (((C +1)/(250) - floor ((C +1)/(250))) = 0)
                    #declare Radius2 = Radius;
                #else
                    #declare Radius2 = Radius2 * (0.01 #if (S1<0) +
((0.1 -(0.01))/(250) *250) #end + ((((SubC1+1) * (0.1 -(0.01))/(250
-1))) * S1));
                #end
                #declare Tx = (1);
                #declare Center = Center + <Tx, 0, 0>;
                #declare Tx2 = (1);
                #declare Center2 = Center2 + <Tx2, 0, 0>;
                #declare Ty = (-5 + (C * (5 - (-5))/(Copies -1)));
                #declare Center = Center + <0, Ty, 0>;
                #declare Ty2 = (-5 + ((C+1) * (5 -(-5))/(Copies -1)));
                #declare Center2 = Center2 + <0, Ty2, 0>;
                #declare Roty = (0 + (C * (360*10 - (0))/(Copies -1)));
                #declare Center = vaxis_rotate (Center, y, Roty);
                #declare Roty2 = (0 + ((C+1) * (360*10 -(0))/(Copies
-1)));
                #declare Center2 = vaxis_rotate (Center2, y, Roty2);
                Center, Radius
                #declare R = (0.000000 + (C * (0.694820
-(0.000000))/(Copies -1)));
                #declare G = (0.000000 + (C * (0.694820
-(0.000000))/(Copies -1)));
                #declare B = (1.000000 + (C * (0.152590
-(1.000000))/(Copies -1)));
                #declare F = (0 + (C * (0 -(0))/(Copies -1)));
                #declare T = (0 + (C * (0 -(0))/(Copies -1)));
                texture { pigment {     rgbft <R, G, B, F, T> } }
                #declare R2 = (0.000000 + ((C+1) * (0.694820
-(0.000000))/(Copies -1)));
                #declare G2 = (0.000000 + ((C+1) * (0.694820
-(0.000000))/(Copies -1)));
                #declare B2 = (1.000000 + ((C+1) * (0.152590
-(1.000000))/(Copies -1)));
                #declare F2 = (0 + ((C+1) * (0 -(0))/(Copies -1)));
                #declare T2 = (0 + ((C+1) * (0 -(0))/(Copies -1)));
            }
            #if ((C+1) < Copies)
                cone {P_C_P ( Center, Radius, R, G, B, F, T, Center2,
Radius2,  R2, G2, B2, F2, T2 )              }
                #declare SubC1 = SubC1+1;
            #end  //#if ((C+1) < Copies)
            #declare C = C +1;
        #end  //while (C < Copies)
    } //union
    
    
cylinder {
    <0, -5, 0>, <0, 5, 0>, 1
    pigment { object { TexObj color rgb <1, 0, 0> color <0, 1, 0> }}
}

//second scene

camera {
    location <0.0, 0.0, -6>
    angle 60
    look_at <0.0, 0.0, 0.0>
}

light_source {
    <0.0, 20, -100>
    rgb <1.0, 1.0, 1.0>
}

#declare StarObj =
union {
        #declare C = 0;
    #declare Copies =20;
            #while ( C < Copies)
        prism {
            linear_spline
            linear_sweep
            0,  //Base height
            2.1,    //Top height
            13,
            <0.25419, 0.00000>,
            <0.86603, 0.50000>,
            <0.14121, 0.24459>,
            <-0.00000, 1.00000>,
            <-0.14121, 0.24459>,
            <-0.86603, 0.50000>,
            <-0.28243, -0.00000>,
            <-0.86603, -0.50000>,
            <-0.14121, -0.24459>,
            <0.00000, -1.00000>,
            <0.14121, -0.24459>,
            <0.86603, -0.50000>,
            <0.25419, 0.00000>
            sturm
            scale <0.3, 1, 0.3>
            rotate x * (-89.5)
            rotate y * (0 + (C * (360)/(Copies -1)))
        } //object
        #declare C = C +1;
    #end  //while (C < Copies)
    }
    

sphere {
    <0.0, 0.0, 0.0>, 2
    pigment { object { StarObj color rgb <1, 0, 0> color <0, 1, 0> }}
}

-- 
e-mail:sme### [at] skynetbe

http://users.skynet.be/smellenbergh

Post a reply to this message

In article <1e2gl0e.1hrykd4wgajkkN%smellenbergh@skynet.be>, 
sme### [at] skynetbe (smellenbergh) wrote:

> The pigment object causes a crash when the object is a CSG construction.

There is a bug in the object pattern, it assumes a declared object will 
stay allocated through the render. The solution is to copy the object, 
and set the pointer in the pattern data structure(proxObj, as I 
remember)to point at that copy. Of course, the object then needs to be 
destroyed when the pattern is destroyed.
The same problem should exist in the proximity pattern, I will upload 
some fixed source soon.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

I posted my latest source, containing just about everything I have done, 
to povray.binaries.programming. This includes slightly tested fixes for 
the object and proximity pattern.(Maybe the proximity pattern will work 
with height fields now, time for some more testing.)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote:

> I posted my latest source, containing just about everything I have done,
> to povray.binaries.programming. This includes slightly tested fixes for
> the object and proximity pattern.(Maybe the proximity pattern will work
> with height fields now, time for some more testing.)
Hi Chris,

We tested the two scenes with your updated sources.
There is improvement. It doesn't crash as often. Rendering one of the
scenes over and over seems ok now. But rendering the two scenes
alternating freezes the computer. 

Could you have another look at it? This patch has potential!

BTW, do you have any recent example scenes (complete ) for the proximity
patch?

Smellenbergh
-- 
e-mail:sme### [at] skynetbe

http://users.skynet.be/smellenbergh

Post a reply to this message

In article <1e2if1h.153on6f1bsrqniN%smellenbergh@skynet.be>, 
sme### [at] skynetbe (smellenbergh) wrote:

> We tested the two scenes with your updated sources.
> There is improvement. It doesn't crash as often. Rendering one of the
> scenes over and over seems ok now. But rendering the two scenes
> alternating freezes the computer. 
> 
> Could you have another look at it? This patch has potential!

Strange, very strange...those patches only affected the pattern data 
structure, there isn't anything going across renders. The only thing I 
did that might need to be reinitialized for each render would be the 
z-buffer patch, but that definitely shouldn't cause a crash.

I added code to copy the object to proxObject, and code to copy the 
object when a pattern was copied, and code to destroy the object. I 
probably goofed in one of the last two, I will try to reproduce the 
crash.

BTW, are you using media with these patterns? Although media probably 
isn't the culprit...


> BTW, do you have any recent example scenes (complete ) for the proximity
> patch?

No, but I can make a few quick ones.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <1e2if1h.153on6f1bsrqniN%smellenbergh@skynet.be>, 
sme### [at] skynetbe (smellenbergh) wrote:

> We tested the two scenes with your updated sources.
> There is improvement. It doesn't crash as often. Rendering one of the
> scenes over and over seems ok now. But rendering the two scenes
> alternating freezes the computer. 

I was unable to reproduce this. I rendered the first one(320*240, no AA) 
then rendered the second, and repeated this, but nothing goes wrong.
Are you using just the sources I uploaded, or are you adding them to 
your version? If you are adding them to your version, make sure add the 
code which copies and destroys proxObj.

Hmn, I don't think this should be a problem, but to destroy the object, 
I used this:
  if(Tpat->proxObject != NULL)
  {
      Destroy_Object((OBJECT *)Tpat->proxObject);
      POV_FREE ((OBJECT *)Tpat->proxObject);
  }
Is the call to POV_FREE necessary? I don't think it is.
I had copied it from Destroy_CSG, and interpreted it as destroying the 
pieces of the object, but not freeing the actual object. Now that I look 
at it more closely, this seems likely to be the problem. Try deleting 
the line
      POV_FREE ((OBJECT *)Tpat->proxObject);
and see if that fixes it.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <chrishuff_99-5D09DB.16383508121999@news.povray.org> , Chris Huff
<chr### [at] yahoocom>  wrote:

> Strange, very strange...those patches only affected the pattern data
> structure, there isn't anything going across renders. The only thing I
> did that might need to be reinitialized for each render would be the
> z-buffer patch, but that definitely shouldn't cause a crash.

Chris, maybe these tips help :-)

Not reproducible crashes, especially on the Mac are most likely caused by
invalid pointers or other out of range addressing. As the Mac OS does not
have full memory protection (yet) these bugs are hard to catch. However,
there are several (free) tricks you can use:
- Use the MacsBug "hs" command to turn on/off heap scrambling.
- When you free memory a pointer points to, set the pointer to NULL.
- Init all pointers and data structures you use to NULL before using them
(even if it looks stupid, i.e. code _should_ always put something into a
pointer).

In general, you should then see either hard crashes (mostly with "hs" on) or
memory access faults when your program tries to write to memory locations
around 0 which are protected by the system. You will also see failing free
calls if the pointers are set to NULL and somewhere code tries to free that
memory again.


        Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <384fcfb1@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Not reproducible crashes, especially on the Mac are most likely caused by
> invalid pointers or other out of range addressing. As the Mac OS does not
> have full memory protection (yet) these bugs are hard to catch.

Yes, I understand that.


> - Use the MacsBug "hs" command to turn on/off heap scrambling.

What exactly is heap scrambling? I know of this command, but I don't 
know what it does.
Also, do you know of a good reference to MacsBug which is available 
online?


> - When you free memory a pointer points to, set the pointer to NULL.
> - Init all pointers and data structures you use to NULL before using them
> (even if it looks stupid, i.e. code _should_ always put something into a
> pointer).

Well, I normally do this, but this is happening just before the data 
structure containing those pointers is destroyed, and those pointers are 
not used after their targets are destroyed. That was the first thing I 
looked at, though.


> In general, you should then see either hard crashes (mostly with "hs" on) 
> or memory access faults when your program tries to write to memory locations
> around 0 which are protected by the system. You will also see failing 
> free calls if the pointers are set to NULL and somewhere code tries to free 
> that memory again.

Well, I think the problem was basically that a function was destroying a 
data structure which I thought I had to destroy separately. Setting the 
pointer to NULL after the call to the first one wouldn't have made sense 
had that been the case, because the first thing I did after that call 
was use POV_FREE on that pointer.

Thanks for the advice, I will be more careful about pointers in the 
future.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote:

[...]
> 
> I was unable to reproduce this. I rendered the first one(320*240, no AA)
> then rendered the second, and repeated this, but nothing goes wrong.
> Are you using just the sources I uploaded, or are you adding them to 
> your version? If you are adding them to your version, make sure add the
> code which copies and destroys proxObj.
We use our GUI but we start with clean sources 3.1g without any
modifications. We throw your sources in the source folder and then
compile.

There is no media, we use the two sources at the start of this chain.

> Hmn, I don't think this should be a problem, but to destroy the object,
> I used this:
>   if(Tpat->proxObject != NULL)
>   {
>       Destroy_Object((OBJECT *)Tpat->proxObject);
>       POV_FREE ((OBJECT *)Tpat->proxObject);
>   }
> Is the call to POV_FREE necessary? I don't think it is.
> I had copied it from Destroy_CSG, and interpreted it as destroying the
> pieces of the object, but not freeing the actual object. Now that I look
> at it more closely, this seems likely to be the problem. Try deleting
> the line
>       POV_FREE ((OBJECT *)Tpat->proxObject);
> and see if that fixes it.
Well, we commented that line out and guess what: no more freezes! 
It seems logic too! :-) (easy to say afterwards, isn't it?)

Smellenbergh

-- 
e-mail:sme### [at] skynetbe

http://users.skynet.be/smellenbergh

Post a reply to this message

Thorsten Froehlich wrote in message <384fcfb1@news.povray.org>...
>Chris, maybe these tips help :-)
>
>Not reproducible crashes, especially on the Mac are most likely caused by
>invalid pointers or other out of range addressing. As the Mac OS does not
>have full memory protection (yet) these bugs are hard to catch. However,
>there are several (free) tricks you can use:
>- Use the MacsBug "hs" command to turn on/off heap scrambling.
>- When you free memory a pointer points to, set the pointer to NULL.
>- Init all pointers and data structures you use to NULL before using them
>(even if it looks stupid, i.e. code _should_ always put something into a
>pointer).
>
>In general, you should then see either hard crashes (mostly with "hs" on)
or
>memory access faults when your program tries to write to memory locations
>around 0 which are protected by the system. You will also see failing free
>calls if the pointers are set to NULL and somewhere code tries to free that
>memory again.


Another thing you can do is in config.h uncomment the lines:
#define MEM_TAG     // Enables memory tag debugging
#define MEM_TRACE   // Enables garbage collection and memory tracing

This will cause the program to alert you to such things as memory leaks and
attempts to free memory twice or free invalid memory locations.

Mark

Post a reply to this message