On 02/19/2017 04:50 AM, ThH wrote:
> Am 03.02.2017 um 16:57 schrieb clipka:
>
>> That's a tricky one: No matter what value we actually choose here, it
>> will always be possible to write /some/ more or less pathological scene
>> that triggers this type of crash.
>>
>> But what we certainly should do is replace the hard-coded value with a
>> macro, which we can then define in the platform-specific compile-time
>> config of the backend module. This way, any user running into such a
>> problem at least has the opportunity to build their own modified binary.
>
> Tried it with Beta 3... Works sometimes ;)
>
> Example 3:
> Render is 38% finished. Speicherzugriffsfehler :(
>
> Example 5:
> Render is 76% finished. Speicherzugriffsfehler :(
>
> The other examples work fine :)
>
This very likely means our new thread stack size is still not large 
enough for those two cases.

As a linux user would you please give the new POV_THREAD_STACK_SIZE 
macro a try?

In the following file:

./unix/povconfig/syspovconfigbackend.h

change the line:

#define POV_THREAD_STACK_SIZE (1024 * 1024 * 4)

to

#define POV_THREAD_STACK_SIZE (1024 * 1024 * 8)

and then recompile.

Normally other ways to do this define/override, but suppose the above 
change is our likely fix for unix - if it works for you.

The 8MB is the size I see as the current default stack size on both my 
32 and 64 bit Ubuntu 16.04 machines. POV-Ray previously picked the 
parent process default on linux and therefore likely 8MB before the code 
went to a fixed size early last year of 2MB for all OSs.

Yep, I wonder why linux seems to need more stack memory than 
windows(2MB). Is the overall memory model different, more efficient 
or...

Lastly, Are you running on a 64bit machine?

We suspect larger stacks might be needed for the 64 bit pointers in the 
stack frames.

Thanks,
Bill P.

Post a reply to this message