I'm getting an interesting seq fault ... I changed some scaling factors 
with a couple of macros in my "ndi" scene and that resulted in the 
number of parsed tokens being increased, and everything was OK until I 
added the shrubs back in (more tokens) ... then seg fault appeared with 
this message ...

Parsing 386364K tokens
File 'PrunedShrub.inc' line 85: Parse Error: std::bad_alloc
Possible Parse Error: Attempt to free NULL pointer.
Fatal error in parser: Cannot parse input.

didn't change #5434 address this

btw: shocked that system monitor showed that it snagged 121MB of my swap 
(RARELY does that). it took a few seconds before the system was it's 
usual responsive self ... still a runaway case?

Post a reply to this message

Jim Holsenback <nom### [at] nomailcom> wrote:
> I'm getting an interesting seq fault ... I changed some scaling factors 
> with a couple of macros in my "ndi" scene and that resulted in the 
> number of parsed tokens being increased, and everything was OK until I 
> added the shrubs back in (more tokens) ... then seg fault appeared with 
> this message ...

> Parsing 386364K tokens
> File 'PrunedShrub.inc' line 85: Parse Error: std::bad_alloc
> Possible Parse Error: Attempt to free NULL pointer.
> Fatal error in parser: Cannot parse input.

> didn't change #5434 address this

> btw: shocked that system monitor showed that it snagged 121MB of my swap 
> (RARELY does that). it took a few seconds before the system was it's 
> usual responsive self ... still a runaway case?

  Some minimal code that causes the error would be helpful...

-- 
                                                          - Warp

Post a reply to this message

On 06/08/2011 10:00 AM, Warp wrote:
> Jim Holsenback<nom### [at] nomailcom>  wrote:
>> I'm getting an interesting seq fault ... I changed some scaling factors
>> with a couple of macros in my "ndi" scene and that resulted in the
>> number of parsed tokens being increased, and everything was OK until I
>> added the shrubs back in (more tokens) ... then seg fault appeared with
>> this message ...
>
>> Parsing 386364K tokens
>> File 'PrunedShrub.inc' line 85: Parse Error: std::bad_alloc
>> Possible Parse Error: Attempt to free NULL pointer.
>> Fatal error in parser: Cannot parse input.
>
>> didn't change #5434 address this
>
>> btw: shocked that system monitor showed that it snagged 121MB of my swap
>> (RARELY does that). it took a few seconds before the system was it's
>> usual responsive self ... still a runaway case?
>
>    Some minimal code that causes the error would be helpful...
>

The scene files that produce this error (and the above error another time):

Parsing 901655K tokens
Fatal error in parser: Cannot parse input.
Render failed

have been posted in p.t.scene-files

when I go into buildings.inc on line 272 and change 0TOScale = 0.25 to 
OTOScale = 0.5 it runs fine ... /NOT/ implying that the OTO macro is the 
problem but the increase in tokens parsed count (from reducing the 
scale) is what's happening here.

Post a reply to this message

> 
> The scene files that produce this error (and the above error another time):
> 
> Parsing 901655K tokens
> Fatal error in parser: Cannot parse input.
> Render failed
> 
> have been posted in p.t.scene-files
> 
> when I go into buildings.inc on line 272 and change 0TOScale = 0.25 to
> OTOScale = 0.5 it runs fine ... /NOT/ implying that the OTO macro is the
> problem but the increase in tokens parsed count (from reducing the
> scale) is what's happening here.

More than 1 Billion (US) tokens and parsing... but Virtual memory
allocated to povray is above 4 Gigabytes.

What is your OS ?

(A 32 bits one might have issue!)

Looks like it goes down to:

Parsing 1435168K tokens
 5223m 3.4g (Virt / Res)

(Res is irrelevant, it is just an indication that most of the 4 GB of
ram is used already on this system (x86_64 linux) by povray and
rendering will be slow due to swap)

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

On 06/08/2011 11:35 AM, Le_Forgeron wrote:
>>
>> The scene files that produce this error (and the above error another time):
>>
>> Parsing 901655K tokens
>> Fatal error in parser: Cannot parse input.
>> Render failed
>>
>> have been posted in p.t.scene-files
>>
>> when I go into buildings.inc on line 272 and change 0TOScale = 0.25 to
>> OTOScale = 0.5 it runs fine ... /NOT/ implying that the OTO macro is the
>> problem but the increase in tokens parsed count (from reducing the
>> scale) is what's happening here.
>
> More than 1 Billion (US) tokens and parsing... but Virtual memory
> allocated to povray is above 4 Gigabytes.
>
> What is your OS ?
>
> (A 32 bits one might have issue!)
>
> Looks like it goes down to:
>
> Parsing 1435168K tokens
>   5223m 3.4g (Virt / Res)
>
> (Res is irrelevant, it is just an indication that most of the 4 GB of
> ram is used already on this system (x86_64 linux) by povray and
> rendering will be slow due to swap)
>
32 bit opensuse11.2

I mean I'm happy with the scale factor set at 0.5 ... but hey I was just 
curious about how it would look at a lower scale ;-) maybe this is just 
a worse case scenario compounded by me being on 32 bit ... but it sounds 
like it's hammering (but working on) your system pretty good. maybe 
others running the latest incantation might weigh in on this, as I'm not 
sure if you'd call what I'm seeing a bug then.

Post a reply to this message