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

On 11/26/2013 12:16 PM, James Holsenback wrote:
> 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

another thought ... might be worth it to have a quick look at latest 
Coverity scan results. I've not looked so your mileage may vary

Post a reply to this message

Am 26.11.2013 18:31, schrieb clipka:
> 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.

BTW, the render abort you experience is probably due to an excessively 
large chunk of memory being passed from one of the render threads to the 
front end.

Post a reply to this message

Am 25.11.2013 05:11, schrieb James Holsenback:

> Rendered 379904 of 705600 pixels (53%)
> Cannot access data in file.
> Rendered 380928 of 705600 pixels (53%)
> Fatal error in renderer: Frontend halted render.

You might want to try the newest version from the "master" branch; I'm 
quite sure it fixes your issue.

Post a reply to this message