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

In article <38533310@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> 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.

I remember seeing those, but didn't know what they did. Thanks for the 
info!

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

Post a reply to this message