Nope. My prob occurs in mega 0.5a., unless of course you mean 0.6

Mark Wagner wrote:


> been fixed in the latest version of MegaPOV, but I'm not sure of this.
>
> Mark

Post a reply to this message

When I do alot of POV work, ie. never close POV and use it continuously for
a long period of time, my machine will die due to memory issues.  I guess
they are associated with memory leaks in the POV engine.  I'm not doing
animations, just rendering the same or different scenes over and over.  This
is least noticible when doing small objects/renders versus very apparent
when doing something complex like my city renders where lots and lots of
objects are repeated via random placement loops.

Robert J Becraft
aka cas### [at] aolcom

John VanSickle <van### [at] erolscom> wrote in message
news:39E71F31.34D2551F@erols.com...
> While woorking on my latest Rusty animation, I've been noticing that the
> peak memory usage figure seems to go up with each frame.  For instance,
> in one shot, the first frame uses 12 megs or so of RAM.  The next frame
> shows about 13.5 megs of RAM, and this peak figure continues to grow as
> long as the sequence is rendering, even though the number of objects
> remains the same.  If I stop rendering, the amount goes back to 12 megs,
> and the memory appears to get released.  On one sequence the peak
> memory figure was over 80 megs when the rendering was down.  I am pretty
> sure that only the original 12 megs is needed for the actual render, and
> with a 96 meg machine I'm not experiencing a virtual memory thrash.
>
> It seems to me that POV-Ray (I'm using the Win95 version) for some
> reason doesn't release everything between frames, but does release
> everything when all frames are done.
>
> Can anyone else confirm this observation, and if so, has it caused any
> genuine problems?
>
> Regards,
> John

Post a reply to this message

I have to restart my machine after a series of test runs with lots of
objects. There is a noticable slowdown but as yet no crashes or out of
memory messages.

Mick

Post a reply to this message

John VanSickle <van### [at] erolscom> wrote in message
news:39E71F31.34D2551F@erols.com...
> It seems to me that POV-Ray (I'm using the Win95 version) for some
> reason doesn't release everything between frames, but does release
> everything when all frames are done.
>
> Can anyone else confirm this observation, and if so, has it caused any
> genuine problems?

John:

I had a play to try to re-create the problem you have experienced - I run
under Windows NT, which has a couple of performance monitoring tools which
lets you examine a programs memory usage somewhat more accurately that Win
9x, I hoped that I might be able to let you know if it was POV-Ray allocated
memory, or memory allocated by Windows on behalf of POV-Ray (i.e. file
buffers, etc) which was growing. Alas I was unable to re-create symptoms you
describe, trying all the scenes I currently have, for the first couple of
frames, POV-Ray does not seem to free up 100% of the memory it had, but by
frame 5, the memory usage is consistently dropping to the same base level
between frames.

As I am running the same code (I assume we are talking POV-Ray Version
3.1g.watcom.win32) this must mean that your 'memory leak' is occurring in
one of the DLL's, or in Windows itself - i.e. the bits that are different in
Win NT. The fact that the memory returns when POV-Ray stops would make me
think that it is Windows itself: Windows performs it's house-keeping and
memory management as a background task, as POV-Ray is CPU intensive, Windows
may be delaying it's garbage collection until it needs to.

A possible way of confirming this might be to watch your memory usage until
it appears that two or three meg has gone adrift, then rather than stopping
POV-Ray, pause it, and minimise it. Wait for the HDD activity to die down,
then bring it back up again. Unpause it and check your memory usage - if I
am correct, the memory will have come back.

If this is the case, then I have two suggestions:
1. Ignore it - if anything, this 'problem' is probably making your machine
run slightly faster than if Windows were to clean up as it goes. When you
run out of physical memory, or try to run another application, Windows will
housekeep existing unallocated memory before resorting to swap-file usage.
2. Run a post-frame command to execute a program which will pause for two or
three seconds before exiting and allowing POV-Ray to continue. N.B. This
pause must be an event triggered pause, not a loop (which would hang up the
CPU as much as POV-Ray does). Hopefully Windows will seize this opportunity
to perform it's garbage collection.

Hope this helps.

Duncan.

N.B. Despite being a programmer myself, I must admit this is largely guess
work.

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:

> This is a known problem with POV-Ray.  I think most of the memory leaks have
> been fixed in the latest version of MegaPOV, but I'm not sure of this.
> 
> Mark

There were many memory leaks fixed in MP 0.6 but some of those fixes
lead to new bugs.
In MegaPOV 0.6a more memory leaks have been fixed. The isosurface object
and pigment had lots and lots of memory leaks. 
They should be fixed now in 0.6a and this time there are, hopefully :-),
no new bugs.
But I would not guarantee that *all* memory leaks are fixed. 

Smellenbergh

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

http://users.skynet.be/smellenbergh

Post a reply to this message

smellenbergh <sme### [at] skynetbe> wrote:
: But I would not guarantee that *all* memory leaks are fixed. 

  This is a big problem in C (and bad-written C++ as well). As the program
gets bigger and bigger it becomes harder and harder to keep track of
memory allocations (and other resources as well) that need to be freed.
  This is because there's no easy way to automatize the construction and
destruction of objects in C (we can speak of objects since povray is largely
object-oriented although it's written in C).
  Using proper OO in C++ should fix most of these problems. Each class handles
its own memory allocation and ensures (in its destructor) that everything
that is handled by the class is also freed.
  Of course using C++ is not fool-proof. It's perfectly possible to make
the same mistakes as in C inside the class. However, minimizing the size
of the class, making it and testing it carefully should minimize the risk
(testing a small class should be easier than testing a big bunch of
C-functions).
  Of course it's also possible to just use news and deletes in other places
than inside classes, thus creating the exact same problem. In my opinion,
however, if this is done, it's a design mistake. I myself seldom use
news and deletes outside well-defined classes (and of course never transfer
the responsibility of freeing the resource to other classes).
  Making small classes which handle carefully their own memory allocation
and freeing is a very powerful tool to get rid of memory leaks.

  By the way, memory is not the only resource that can be allocated and
freed. There are others as well, for example file handlers (ie. opened and
closed files), network connections, printers and so on. There can be also
program-specific resources that have to be allocated and freed.
  For this reason the Java-ideology is not good.
  In Java objects are allocated but the user doesn't have to free them. This
is good for memory handling, but it's bad for other resources.
  If the objects has to perform some operations before being destroyed
(such as closing files, internet connections or whatever), the user has
to call its "destructor" by hand. It's not called automatically. This will
inevitable cause resource leaks in bigger programs.
  Yes, I know that there's some kind of destructor function that can be defined
to a class in Java. This destructor is called before the memory taken by
the object is freed.
  However, this has a big problem: It's perfectly possible that the destructor
is never called. If the object is never freed (because the program just
finishes), then the destructor is never called.
  This is a big problem because some resources may not be freed at all.
However, even if the destructor is called, the problem is that you don't
know when it's called. If the object, for example, opens a window on screen
and closes it in its destructor, you'll probably get quite a lot of garbage
windows on the screen before they are eventually closed (if ever).

  Darn, I didn't mean to write a long story like this.
  Just forget it :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39eb0544@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   This is a big problem in C (and bad-written C++ as well). As the program
> gets bigger and bigger it becomes harder and harder to keep track of
> memory allocations (and other resources as well) that need to be freed.
>   This is because there's no easy way to automatize the construction and
> destruction of objects in C (we can speak of objects since povray is largely
> object-oriented although it's written in C).

POV-Ray has build-in memory management.  Depending of compile-time settings
it can either just keep track of all allocated memory and free it at the end
of a render (i.e. after the last frame of an animation has been rendered),
or even create a log file of all not freed blocks of memory, together with
the line in which they were allocated.  There are some more options, but
just look for yourself in mem.c/pov_mem.cpp. Usually this is a big help in
finding leaks.


    Thorstem

____________________________________________________
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

Thorsten Froehlich <tho### [at] trfde> wrote:
: POV-Ray has build-in memory management.  Depending of compile-time settings
: it can either just keep track of all allocated memory and free it at the end
: of a render (i.e. after the last frame of an animation has been rendered),
: or even create a log file of all not freed blocks of memory, together with
: the line in which they were allocated.  There are some more options, but
: just look for yourself in mem.c/pov_mem.cpp. Usually this is a big help in
: finding leaks.

  Yes, that kind of "self-made" memory management is of big help, of course.
  What I wonder is that if that library can report unfreed memory at the
end of the program, why there are memory leaks in povray?

  Btw, not freeing allocated memory in the right place but letting the
library to do it is usually a sign of a bug.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39eb2b09@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Yes, that kind of "self-made" memory management is of big help, of course.
>   What I wonder is that if that library can report unfreed memory at the
> end of the program, why there are memory leaks in povray?

Yes, this memory management will not only report the unfreed memory but also
free it, again depending on a compile-time setting.  Unfortunately this is
not possible after every frame of an animation (because some memory remains
allocated), so only after rendering is complete they will free the memory,
and only then any OS specific cleanup (or heap compacting) can take place.

Unfortunately very few patch authors seem to be aware of this capability and
so MegaPOV seems to leak a bit more than POV-Ray 3.1g (also, at least as far
as I know, there shouldn't be any leaks in the core code in 3.1g).

It is up to anyone to check, just add these defines to config.h and make
sure they are not set to 0 anywhere else.  Then do a full rebuild.

#define MEM_RECLAIM  1
#define MEM_TAG      1
#define MEM_TRACE    1
#define MEM_STATS    1

>   Btw, not freeing allocated memory in the right place but letting the
> library to do it is usually a sign of a bug.

Yes, and depending on the compile-time setting it will (hopefully) report
it.


     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 <39eb2b09@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   What I wonder is that if that library can report unfreed memory at the
> end of the program, why there are memory leaks in povray?

Because in testing, you have to cause the leak to know it is there. If 
the isosurface object leaks, you won't know unless you happen to be 
testing the isosurface object when you have logging on. And you don't 
want to have the memory logging feature on all the time, since it can 
slow things down.
Also, it is sometimes a bit difficult to find out why some things are 
leaking...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message