Am 25.11.2013 21:14, schrieb James Holsenback:
> On 11/24/2013 11:11 PM, James Holsenback wrote:
>> Rendered 379904 of 705600 pixels (53%)
>> Cannot access data in file.
>> Rendered 380928 of 705600 pixels (53%)
>> Fatal error in renderer: Frontend halted render.
>>
>> Dunno if it was related to the above problem ... just thought I'd
>> mention it anyways
>
> decreased +am3 aa depth from +r6 to +r4 and abort went away ...

This must be something deep in the bowels of the POVMS message-passing 
code; can you try the following - in source/base/povmscpp.cpp, replace all

     throw POV_EXCEPTION_CODE(pov_base::kFileDataErr)

with

     throw POV_EXCEPTION_CODE(pov_base::kFileDataErr, "FUBAR: ###")

where ### is different for each instance (ideally the line number), then 
compile & try again, and report which line claims the jackpot?


What are your system specs?

Post a reply to this message

On 11/25/2013 03:48 PM, clipka wrote:
> Am 25.11.2013 21:14, schrieb James Holsenback:
>> On 11/24/2013 11:11 PM, James Holsenback wrote:
>>> Rendered 379904 of 705600 pixels (53%)
>>> Cannot access data in file.
>>> Rendered 380928 of 705600 pixels (53%)
>>> Fatal error in renderer: Frontend halted render.
>>>
>>> Dunno if it was related to the above problem ... just thought I'd
>>> mention it anyways
>>
>> decreased +am3 aa depth from +r6 to +r4 and abort went away ...
>
> This must be something deep in the bowels of the POVMS message-passing
> code; can you try the following - in source/base/povmscpp.cpp, replace all
>
>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr)
>
> with
>
>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr, "FUBAR: ###")
>
> where ### is different for each instance (ideally the line number), then
> compile & try again, and report which line claims the jackpot?

I'll do that later this evening ...

>
> What are your system specs?
>

amd athlon x2 250 4gb ram

Post a reply to this message

Am 25.11.2013 22:52, schrieb James Holsenback:

>> What are your system specs?
>
> amd athlon x2 250 4gb ram

That's a 64 bit machine AFAIK; otherwise my first suspect would have 
been /some/ variable /somewhere/ with just 32 bit where 64 bit would 
have been required for whatever you're doing there.

Post a reply to this message

On 11/25/2013 03:48 PM, clipka wrote:
> Am 25.11.2013 21:14, schrieb James Holsenback:
>> On 11/24/2013 11:11 PM, James Holsenback wrote:
>>> Rendered 379904 of 705600 pixels (53%)
>>> Cannot access data in file.
>>> Rendered 380928 of 705600 pixels (53%)
>>> Fatal error in renderer: Frontend halted render.
>>>
>>> Dunno if it was related to the above problem ... just thought I'd
>>> mention it anyways
>>
>> decreased +am3 aa depth from +r6 to +r4 and abort went away ...
>
> This must be something deep in the bowels of the POVMS message-passing
> code; can you try the following - in source/base/povmscpp.cpp, replace all
>
>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr)
>
> with
>
>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr, "FUBAR: ###")

error: macro "POV_EXCEPTION_CODE" passed 2 arguments, but takes just 1

Post a reply to this message

Am 26.11.2013 04:33, schrieb James Holsenback:

>> This must be something deep in the bowels of the POVMS message-passing
>> code; can you try the following - in source/base/povmscpp.cpp, replace
>> all
>>
>>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr)
>>
>> with
>>
>>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr, "FUBAR: ###")
>
> error: macro "POV_EXCEPTION_CODE" passed 2 arguments, but takes just 1

My bad - that should have been:

     throw POV_EXCEPTION(pov_base::kFileDataErr, "FUBAR: ###")

Post a reply to this message

On 11/26/2013 07:42 AM, clipka wrote:
> Am 26.11.2013 04:33, schrieb James Holsenback:
>
>>> This must be something deep in the bowels of the POVMS message-passing
>>> code; can you try the following - in source/base/povmscpp.cpp, replace
>>> all
>>>
>>>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr)
>>>
>>> with
>>>
>>>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr, "FUBAR: ###")
>>
>> error: macro "POV_EXCEPTION_CODE" passed 2 arguments, but takes just 1
>
> My bad - that should have been:
>
>      throw POV_EXCEPTION(pov_base::kFileDataErr, "FUBAR: ###")
>

This run got a little farther .... used +am3 aa depth +r5

Rendered 553984 of 705600 pixels (78%)
Belch: 1494
Rendered 555008 of 705600 pixels (78%)
Fatal error in renderer: Frontend halted render.
Render failed

btw: amd x2 250 is 32-bit dual core ... fwiw: 3.1.10-1.29-desktop kernel 
opensuse 12.1

Post a reply to this message

Am 26.11.2013 16:50, schrieb James Holsenback:
> On 11/26/2013 07:42 AM, clipka wrote:
>> Am 26.11.2013 04:33, schrieb James Holsenback:
>>
>>>> This must be something deep in the bowels of the POVMS message-passing
>>>> code; can you try the following - in source/base/povmscpp.cpp, replace
>>>> all
>>>>
>>>>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr)
>>>>
>>>> with
>>>>
>>>>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr, "FUBAR: ###")
>>>
>>> error: macro "POV_EXCEPTION_CODE" passed 2 arguments, but takes just 1
>>
>> My bad - that should have been:
>>
>>      throw POV_EXCEPTION(pov_base::kFileDataErr, "FUBAR: ###")
>>
>
> This run got a little farther .... used +am3 aa depth +r5
>
> Rendered 553984 of 705600 pixels (78%)
> Belch: 1494
> Rendered 555008 of 705600 pixels (78%)
> Fatal error in renderer: Frontend halted render.
> Render failed
>
> btw: amd x2 250 is 32-bit dual core ... fwiw: 3.1.10-1.29-desktop kernel
> opensuse 12.1

Duh.. sure it's 32 bit? All I can find on the 'net says that it must be 
either an "AMD Athlon 64 x2", or an "AMD Athlon x2" - but the latter is 
a 64-bit thing, too. Even the notebook variant is.

Still, you're possibly running a 32-bit OS on it, so that brings integer 
size issues back on the list of suspects.

Post a reply to this message

Am 26.11.2013 16:50, schrieb James Holsenback:
> On 11/26/2013 07:42 AM, clipka wrote:
>> Am 26.11.2013 04:33, schrieb James Holsenback:
>>
>>>> This must be something deep in the bowels of the POVMS message-passing
>>>> code; can you try the following - in source/base/povmscpp.cpp, replace
>>>> all
>>>>
>>>>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr)
>>>>
>>>> with
>>>>
>>>>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr, "FUBAR: ###")
>>>
>>> error: macro "POV_EXCEPTION_CODE" passed 2 arguments, but takes just 1
>>
>> My bad - that should have been:
>>
>>      throw POV_EXCEPTION(pov_base::kFileDataErr, "FUBAR: ###")
>>
>
> This run got a little farther .... used +am3 aa depth +r5
>
> Rendered 553984 of 705600 pixels (78%)
> Belch: 1494

Still doesn't make much sense to me. Mind e-mailing the complete scene + 
all render settings? (See the dev newsgroup for my e-mail address).

Post a reply to this message

On 11/26/2013 11:32 AM, clipka wrote:
> Am 26.11.2013 16:50, schrieb James Holsenback:
>> On 11/26/2013 07:42 AM, clipka wrote:
>>> Am 26.11.2013 04:33, schrieb James Holsenback:
>>>
>>>>> This must be something deep in the bowels of the POVMS message-passing
>>>>> code; can you try the following - in source/base/povmscpp.cpp, replace
>>>>> all
>>>>>
>>>>>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr)
>>>>>
>>>>> with
>>>>>
>>>>>      throw POV_EXCEPTION_CODE(pov_base::kFileDataErr, "FUBAR: ###")
>>>>
>>>> error: macro "POV_EXCEPTION_CODE" passed 2 arguments, but takes just 1
>>>
>>> My bad - that should have been:
>>>
>>>      throw POV_EXCEPTION(pov_base::kFileDataErr, "FUBAR: ###")
>>>
>>
>> This run got a little farther .... used +am3 aa depth +r5
>>
>> Rendered 553984 of 705600 pixels (78%)
>> Belch: 1494
>
> Still doesn't make much sense to me. Mind e-mailing the complete scene +
> all render settings? (See the dev newsgroup for my e-mail address).
>

a little bit too big to email ~15MB, so I put it on my wiki testbed ... 
see your email for the link

Post a reply to this message

Am 26.11.2013 18:16, schrieb James Holsenback:
>>
>> Still doesn't make much sense to me. Mind e-mailing the complete scene +
>> all render settings? (See the dev newsgroup for my e-mail address).
>>
>
> a little bit too big to email ~15MB, so I put it on my wiki testbed ...
> see your email for the link

Thanks, but I guess I've nailed down the culprit already - after 
accidently getting my Windows system into swap hell by "nothing more" 
than cranking up the AA mode 3 quality settings (something like +am3 
+ac0.999 +a0.001 +r9). The quality settings shouldn't have any effect on 
the memory consumption during AA mode 3, but obviously they do.

That was the clue I needed. Turned out to be a stupid bug, actually.

Post a reply to this message