POV-Ray : Newsgroups : povray.beta-test : "Bad allocation" in POV-Ray RC3 for WIndows : Re: "Bad allocation" in POV-Ray RC3 for WIndows Server Time
1 Jun 2024 21:30:50 EDT (-0400)
  Re: "Bad allocation" in POV-Ray RC3 for WIndows  
From: Jim Holsenback
Date: 12 Apr 2011 13:36:01
Message: <4da48d81$1@news.povray.org>
On 04/12/2011 01:54 PM, Warp wrote:
> Jim Holsenback<jho### [at] povrayorg>  wrote:
>> On 04/11/2011 09:41 PM, Tor Olav Kristensen wrote:
>>>
>>> I get this error message:
>>> "Parse Error: bad allocation  Render failed"
>>> - after the code below has been running for about 3 seconds.
>>>
>>> // ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
>>>
>>> #version 3.7;
>>>
>>> #while (true)
>>>     #local Fn = function { transform { translate<0, 0, 0>   } }
>>>     #undef Fn
>>> #end // while
>
>> where does the conditional get set to false ... don't see that here (or
>> any other bail-out mechanism) ... runaway loop?
>
>    I don't think that's the point. The above code doesn't look like it should
> give any kind of error. Instead, it should just run indefinitely.
>
LOL ... on a more serious note I do believe that I've been seeing this 
manifest itself slightly different on 32bit linux

sometimes my scene would parse the just as it pops up the preview window 
it freezes, and requires a kill -9 to get it to let go. After the kill 
-9 and with no scene file changes and resubmit the render ... it worked 
just fine. One time I let it keep going because I'd thought I was being 
impatient ... next morning it was still hung and fuxtex or mutex (I 
forget) was the process table hog ... that's boost trying to allocate 
correct?

IIRC ... this started about the time we didn't have to specify the boost 
configure option ... maybe just a co-incidence.

this last cycle (RC3-RC4) there were one or two problems that couldn't 
be duplicated on 64bit systems ... that is ... they were problems that 
in one way or another couldn't be confirmed by the developers until I 
learned how to use gdb and supplied more useful information

maybe this is another one of those 32 -vs- 64bit scoundrels ... does the 
win32 bit problem that started this thread offer to send a mini dump? on 
linux hard fails like this usually has a segmentation fault, but like I 
mentioned mine never did (seg fault) it just hung and continued to 
consume cpu cycles


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.