 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3fa168a4$1@news.povray.org> , "Scott Gammans"
<dee### [at] yahoo com> wrote:
> I may be wrong about what is causing the problem, but POV-Ray for Windows
> *does* have some sort of memory allocation problem that, after a few dozen
> frames, causes it to stop rendering with a memory allocation error because
> it can't allocate any more memory to open one of the TGA bump map files in
> my scene.
I guess you can also explain why these groups aren't full of people
complaining about it then. It is not like there aren't enough people using
the animation loop in POV-Ray, i.e. for the irtc...
> You will never be able to convince me that there is no problem with
> long-running, memory-intensive animation jobs in POV-Ray, Thorsten, because
> I've seen it happen.
I don't need to convince you. I know there is no memory leak big enough
that it could cause what you claim it would - for your claim to be correct
POV-Ray would have to forget about tens of megabytes of memory per frame!
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Scott Gammans wrote:
>
>
> I may be wrong about what is causing the problem, but POV-Ray for Windows
> *does* have some sort of memory allocation problem that, after a few dozen
> frames, causes it to stop rendering with a memory allocation error because
> it can't allocate any more memory to open one of the TGA bump map files in
> my scene.
I've had POVRay crash on Windows because of memory problems when running
(long) animation renders.
I'm not sure the problem lies with POVRay though.
When working on a program that would continuously load images a similar
(perhaps the same) problem occurred. I checked my code hundreds of times
but couldn't find any error, then tried to eliminate all non related
routines until finally I was left with a program that would only load an
image file. When running for a long time it would slowly eat away
Windows memory as was show with the resource monitor (or whatever it's
called).
There was nothing in my program I could change to avoid that (well, I
found a solution, but that's not relevant here).
So there may indeed be a memory leak occurring when you render
animations with POVRay that need to load a lot of images. The solution
would probably be not to reload image maps for each scene but to keep
them in memory.
Just my 2.5 cents.
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Remco de Korte wrote:
>When working on a program that would continuously load images a similar
>(perhaps the same) problem occurred. I checked my code hundreds of times
>but couldn't find any error, then tried to eliminate all non related
>routines until finally I was left with a program that would only load an
>image file. When running for a long time it would slowly eat away
>Windows memory as was show with the resource monitor (or whatever it's
>called).
>There was nothing in my program I could change to avoid that (well, I
>found a solution, but that's not relevant here).
>
>So there may indeed be a memory leak occurring when you render
>animations with POVRay that need to load a lot of images.
Yes, that is exactly, EXACTLY the behavior I have seen in the past.
>The solution
>would probably be not to reload image maps for each scene but to keep
>them in memory.
Would you mind explaining what you mean by that? Is this a suggestion for
the POV-Ray developers for the next version of POV-Ray, or are you
suggestion a technique that I can implement using the SDL? And if it's the
latter, please provide a brief SDL example of what you are talking about.
Many thanks...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK, I am seeing the same pattern of behavior on MacMegaPOV that I've
observed on long-running Windows POV-Ray animation renders.
I started another animation series at frame 942 at 5:30 PM yesterday
afternoon, and the OS X System Activity monitor showed MacMegaPOV consuming
just under 600 MB of memory, which was about right for the scene file I'm
rendering. But at 11:42 PM on frame 971 (30 frames into the job), the
amount of memory being used by MacMegaPOV had *tripled* to 1.5 GB. And at
5:30 AM on frame 1000 (59 frames along), the memory in use by MacMegaPOV is
a whopping 2.05 GB, with nearly all of the physical memory on my
workstation (2.5 GB) in use.
At the current rate of frame completion, MMP should get to frame 1004 (the
63rd frame in this series) in about 40 minutes. I wonder if the program
stops
because it runs out of physical memory, which at the current rate of memory
leakage will almost certainly occur by that 63rd frame? I'll post a message
to let everyone know what happens (unlike the last time, this time I have
all output streams being directed to a file, so hopefully when MMP aborts
I'll have something tangible I can show you).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, it must know I'm watching it like a hawk, because now it refuses to do
*anything* while it's parsing frame 1004. The System Activity monitor shows
that CPU activity is nil, memory consumption is 2.05 GB, and it's been
parsing the same scene file for 14 minutes now (just parsing, no
rendering). I ran a sample of what the program is doing (OS X has all kinds
of neat little goodies for checking on what a program is up to!) and I
copied below what was reported back. It looks like MMP is hung on something
called a "semaphore_wait_signal_trap". I'm just gonna kill it and restart
the sequence at frame 1004... don't have time to wait around for the
program to do something interesting, like actually *render* something (or
crash).
===============
2003-10-31 06:27:06.959 sample[702] Couldn't start c++filt for C++ name
demangling
Analysis of sampling pid 517 every 10.000000 milliseconds
Call graph:
228 Thread_0e0b
228 0x40e440
228 0x50e57c
228 0x50e32c
228 0x514da8
228 0x514a98
228 0x514a04
228 0x50edc0
228 0x4becc4
228 0x52c08c
228 0x50ed38
228 0x50edc0
228 0x4157e0
228 0x4107f0
228 0x512b7c
228 0x4bbce8
228 0x410860
228 0x5091c4
228 AESend
228 aeSend
228 AESendMessage
228
_Z10sendToSelfPK6AEDescPS_ll
228
_Z20aeDispatchAppleEventPK6AEDescPS_mPh
228 0x502ed4
228 0x5041d0
228 0x5056c0
228 0x40f030
228 0x4140ec
228 0x636c98
228 0x6368c8
228 0x635fac
228
0x611cb4
228
0x6088a4
228
0x608eac
228
0x60ede0
228 0x608fa0
228 0x608eac
228 0x60ede0
228 0x608b5c
228 0x659694
228 0x657874
228 0x605db0
228 0x6053a4
228 0x6182dc
228 0x61a6fc
228 0x5d7fe4
228 0x6180a0
228 0x61ac04
228 0x619570
228 0x61b15c
228 0x61ba54
228 0x6278dc
228 0x62fa8c
228 0x604150
228 0x661e48
228 0x658114
228 0x478798
228 0x40bf94
228 0x4ce530
228 0x4ca2f0
228 0x52b018
228 SizeWindow
228
_Z24MoveResizeWindowInternalP10WindowDatasssshhhhPK4Rectm
228
_ZN10WindowData14MoveResizeRgnsEssssb
228
_Z22CalculateWindowRegionsP10WindowDatab
228
ResetPlatformWindowShape
228
SetPlatformWindowShape
228
CGSSetWindowShapeWithWeighting
228
CGSRWLockLockForWriting
228
_pthread_cond_wait
228
semaphore_wait_signal_trap
228
semaphore_wait_signal_trap
Total number in stack (recursive counted multiple, when >=5):
Sort by top of stack, same collapsed (when >= 5):
semaphore_wait_signal_trap 228
Sample analysis of process 517 written to file /dev/stdout
Sampling process 517 each 10 msecs 300 times
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Scott Gammans wrote:
>
> >So there may indeed be a memory leak occurring when you render
> >animations with POVRay that need to load a lot of images.
>
> Yes, that is exactly, EXACTLY the behavior I have seen in the past.
>
> >The solution
> >would probably be not to reload image maps for each scene but to keep
> >them in memory.
>
> Would you mind explaining what you mean by that? Is this a suggestion for
> the POV-Ray developers for the next version of POV-Ray, or are you
> suggestion a technique that I can implement using the SDL? And if it's the
> latter, please provide a brief SDL example of what you are talking about.
>
> Many thanks...
It's a solution I used in the program I mentioned. It had to load
graphics data continuously and the only way I could solve it is to load
everything only one time and then keep it in memory.
For a POVRay animation render that would mean that it would keep
imagemaps and such in memory until the end of the render instead of
loading them for each frame, but to be honest I don't know how POVRay
handles things now, I'm only assuming it doesn't do this already.
So, obviously, this is not a solution you can achieve with the SDL. It
may only help to know that cutting down on the image loading *might*
help.
What puzzles me is how this could occur on Mac as well though...
When I ran into this problem and found that the cause wasn't in my own
code (eliminating almost all of it didn't solve it) I figured that it
was something in the way Windows (98 at the time) handles files.
Now I think that it could also have been somewhere in between (the code
that loads and decodes the images); I realize this seems vague, but I
didn't get any further then that... :)
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, I am convinced that MacMegaPOV has the same memory leak (or
**whatever** you want to call it, Thorsten!) that plagues the Windows
version when it comes to loading and unloading lots of large image maps
over a series of animation passes. The exact same problem happened
**AGAIN** with yet another animation job... the only difference this time
around was that I started rendering at frame 1055 and it froze after
completing frame 1117--the dreaded 63rd frame.
I'm in the middle of trying to get a project finished, but when I have some
free time I'm going to upload the files to the binaries section to prove
that what I'm seeing isn't just some figment of my imagination. Who
knows--maybe I'm doing something in the SDL that is causing WinPOV and
MacMegaPOV to slowly leak memory, and I'd be perfectly happy for Thorsten
to point out the foolish error of my ways so I can continue using
MacMegaPOV on my G5. As things stand now, though, I can't reliably use
software that buggers itself after a few dozen invocations.
Remco de Korte wrote:
>Scott Gammans wrote:
>>
>> >So there may indeed be a memory leak occurring when you render
>> >animations with POVRay that need to load a lot of images.
>>
>> Yes, that is exactly, EXACTLY the behavior I have seen in the past.
>>
>> >The solution
>> >would probably be not to reload image maps for each scene but to keep
>> >them in memory.
>>
>> Would you mind explaining what you mean by that? Is this a suggestion for
>> the POV-Ray developers for the next version of POV-Ray, or are you
>> suggestion a technique that I can implement using the SDL? And if it's the
>> latter, please provide a brief SDL example of what you are talking about.
>>
>> Many thanks...
>
>It's a solution I used in the program I mentioned. It had to load
>graphics data continuously and the only way I could solve it is to load
>everything only one time and then keep it in memory.
>For a POVRay animation render that would mean that it would keep
>imagemaps and such in memory until the end of the render instead of
>loading them for each frame, but to be honest I don't know how POVRay
>handles things now, I'm only assuming it doesn't do this already.
>
>So, obviously, this is not a solution you can achieve with the SDL. It
>may only help to know that cutting down on the image loading *might*
>help.
>
>What puzzles me is how this could occur on Mac as well though...
>When I ran into this problem and found that the cause wasn't in my own
>code (eliminating almost all of it didn't solve it) I figured that it
>was something in the way Windows (98 at the time) handles files.
>Now I think that it could also have been somewhere in between (the code
>that loads and decodes the images); I realize this seems vague, but I
>didn't get any further then that... :)
>
>Remco
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3fa3b203944a788685aba4bf0@news.povray.org> , "Scott Gammans"
<deepgloathatesspamaatyahoodotcom> wrote:
> Well, I am convinced that MacMegaPOV has the same memory leak (or
> **whatever** you want to call it, Thorsten!)
As POV-Ray is able to track all memory used, and that tracking will show all
memory "Lost" and then free it anyway, there is no memory leak. It is that
simple. Just repeating something that sin't a fact does not make it a
fact...
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 <web.3fa3b203944a788685aba4bf0@news.povray.org> , "Scott Gammans"
<deepgloathatesspamaatyahoodotcom> wrote:
> The exact same problem happened
> **AGAIN** with yet another animation job... the only difference this time
> around was that I started rendering at frame 1055 and it froze after
> completing frame 1117--the dreaded 63rd frame.
If you are so sure it ahppens with all animations, why don't you post a
scene that "shows" the problem in scene file binary group? Please remember
to include the INI file used to render it as well!
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
news:3fa3ca69@news.povray.org...
> If you are so sure it ahppens with all animations, why don't you post a
> scene that "shows" the problem in scene file binary group? Please
remember
> to include the INI file used to render it as well!
For the record, I think there may be something fishy with the loading of
large image maps. I had a problem recently (official POV, Windows XP) with
one JPEG (9000*4500): the scene rendered OK a few times and then BLAM!,
POV-Ray returned a message saying that it couldn't load the image due to
(IIRC, didn't write it down) a pointer problem. After closing and reloading
POV-Ray, the scene ran fine again. It happened several times, but as it was
a 4000-line scene that took several minutes to parse and used 1Gb or RAM,
bug hunting wasn't exactly easy. I didn't use the map eventually and the
problem never resurfaced. I've tried to replicate it with a simpler scene
including the map, at least to write down the error message, but everything
was OK (no unusual memory consumption in successive runs).
I've also seen POV-Ray suddenly complaining about a missing image map
between 2 successful runs of the same (unchanged) script. Again, this was
impossible to replicate.
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
