On Sun, 24 Feb 2013 10:27:12 +0100, Le_Forgeron wrote:

I too am running this on the linux RC7 version to try to narrow down the 
issue. In my case:

CPU: Intel i7-3770K Quad Core Overclocked to 4.5GHz (I love saying that!)
RAM: 16GB
OS:  Fedora 18 x86_64

 
> Should I presume +KFI0 +KFF360 +KI0 +KF1 ?
> (361 frames, initial clock 0, final clock 1) ?

Line 625 is the start of a series of #if's for each frame starting at 1. 
The clock variable is not referred to at all.

I used:
povray +w1920 +h1080 +KFI1 +KFF360 Scene_def.pov
 
> (PS: 124 hard-coded paths of include, arghh... <3 I also got a warning
> on each inc, about a null normal vector)
> )

I had the same warnings as you.

I did a search and replace to make the path to the include files 
relative, no other changes to the source.

Still running after over 20 hours, but no errors so far.
160 frames generated of what looks like to be a wonderful animation.

Is the bug limited to the Windows version?

-- 
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Dave Downing,  Somerset U.K.
No bytes were harmed in the making of this message.

Post a reply to this message

Le 24/02/2013 11:56, Dave Downing nous fit lire :
> I too am running this on the linux RC7 version to try to narrow down the 
> issue. 

I want to reproduce it before trying something from Christoph Lipka
(clipka).

> Still running after over 20 hours, but no errors so far.
> 160 frames generated of what looks like to be a wonderful animation.
> 
> Is the bug limited to the Windows version?

Nope, but tied to the system memory management if the symptoms are
correct (rare condition), and if I got it correctly from the explanations.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> > 
> > Is the bug limited to the Windows version?
> 
> Nope, but tied to the system memory management if the symptoms are
> correct (rare condition), and if I got it correctly from the explanations.
Happens always after the first frame on Mac.
It takes a lot of time before all memory is released after a frame,
maybe too long?

Yvo


-- 
-----------------------------------
MegaPOV at:  http://megapov.inetart.net
MacMegaPOV at:  http://users.skynet.be/smellenbergh
E-mail: yvo(DOT)s(AT)gmx.net

Post a reply to this message

Am 24.02.2013 12:23, schrieb Yvo Smellenbergh:
> Le_Forgeron <jgr### [at] freefr> wrote:
>
>>>
>>> Is the bug limited to the Windows version?
>>
>> Nope, but tied to the system memory management if the symptoms are
>> correct (rare condition), and if I got it correctly from the explanations.
> Happens always after the first frame on Mac.

Congrats, you've just volunteered to be our guinea pig for a solution :-)

I've shelved a few files in change #5817 (Workspace cli-pc-7) that 
should fix the issue if our assumptions about the root cause are 
correct; as far as I understand you should be able to access those 
files, so if you wouldn't mind test-driving them...?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 23.02.2013 21:46, schrieb clipka:
>
> >> Any suggestions on how to tackle this problem?
> >
> > Yup: Please add a comment to http://bugs.povray.org/task/257; it sounds
> > to me like the issue hasn't been fixed for good yet.
>
> One more thing: Please make a backup of the scene in its current state;
> we currently don't know how common the issue is, so we might need your
> scene (and you and your computer) as guinea pig once we come up with a
> solution candidate.

Sure - no problem! FYI - I also tested it on another PC (128 GB RAM with 24
threads)... same issue there.

> If you can trim down the scene a bit while still reproducing the error,
> that would be a great help as well.

So this is the weird thing: including only one or a few of the *.inc files and
then, there is no error anymore! So it seems the size of the scene matters...

Post a reply to this message

Dave Downing <cis### [at] hotmailcom> wrote:
> On Sun, 24 Feb 2013 10:27:12 +0100, Le_Forgeron wrote:
>
> I too am running this on the linux RC7 version to try to narrow down the
> issue. In my case:
>
> CPU: Intel i7-3770K Quad Core Overclocked to 4.5GHz (I love saying that!)
> RAM: 16GB
> OS:  Fedora 18 x86_64
>
>
> > Should I presume +KFI0 +KFF360 +KI0 +KF1 ?
> > (361 frames, initial clock 0, final clock 1) ?
>
> Line 625 is the start of a series of #if's for each frame starting at 1.
> The clock variable is not referred to at all.
>
> I used:
> povray +w1920 +h1080 +KFI1 +KFF360 Scene_def.pov
>
> > (PS: 124 hard-coded paths of include, arghh... <3 I also got a warning
> > on each inc, about a null normal vector)
> > )
>
> I had the same warnings as you.
>
> I did a search and replace to make the path to the include files
> relative, no other changes to the source.
>
> Still running after over 20 hours, but no errors so far.
> 160 frames generated of what looks like to be a wonderful animation.

I'm somewhat having a deadline... would you be able to send me the 360 frames
rendered at 1920 x 1080 (AA 0.3)?

> Is the bug limited to the Windows version?
>
> --
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> Dave Downing,  Somerset U.K.
> No bytes were harmed in the making of this message.

Post a reply to this message

Am 25.02.2013 22:46, schrieb Alex:

> So this is the weird thing: including only one or a few of the *.inc files and
> then, there is no error anymore! So it seems the size of the scene matters...

Yvo was able to help investigating this issue, and it seems that yes, 
memory consumption is the key after all: The backend seems to take 
longer to free the allocated memory than the frontend is willing to wait.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 25.02.2013 22:46, schrieb Alex:
>
> > So this is the weird thing: including only one or a few of the *.inc files and
> > then, there is no error anymore! So it seems the size of the scene matters...
>
> Yvo was able to help investigating this issue, and it seems that yes,
> memory consumption is the key after all: The backend seems to take
> longer to free the allocated memory than the frontend is willing to wait.

Great news - when do you think this will be resolved? In other words, when will
I be able to download a version without this bug? Just worried I'll miss the
deadline :-(!

Post a reply to this message

On 02/25/2013 05:08 PM, clipka wrote:
> Am 25.02.2013 22:46, schrieb Alex:
>
>> So this is the weird thing: including only one or a few of the *.inc
>> files and
>> then, there is no error anymore! So it seems the size of the scene
>> matters...
>
> Yvo was able to help investigating this issue, and it seems that yes,
> memory consumption is the key after all: The backend seems to take
> longer to free the allocated memory than the frontend is willing to wait.
>
I haven't been following this thread closely so maybe this won't be any 
help, but nevertheless I feel compelled to mention the six resource leak 
bugs uncovered by Coverity ... CID's #967298-#967303 ... these were 
found in either parse.cpp or parsestr.cpp

Post a reply to this message

On 02/25/2013 07:15 PM, James Holsenback wrote:
> On 02/25/2013 05:08 PM, clipka wrote:
>> Am 25.02.2013 22:46, schrieb Alex:
>>
>>> So this is the weird thing: including only one or a few of the *.inc
>>> files and
>>> then, there is no error anymore! So it seems the size of the scene
>>> matters...
>>
>> Yvo was able to help investigating this issue, and it seems that yes,
>> memory consumption is the key after all: The backend seems to take
>> longer to free the allocated memory than the frontend is willing to wait.
>>
> I haven't been following this thread closely so maybe this won't be any
> help, but nevertheless I feel compelled to mention the six resource leak
> bugs uncovered by Coverity ... CID's #967298-#967303 ... these were
> found in either parse.cpp or parsestr.cpp

correction ... five bugs starting at CID #967299 /instead of/ #967298

Post a reply to this message