 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rendering some old files I had an error with attractor.pov (source
p.t.s-f, 20.08.2008, 'Attractor include and demo', Author: Rob)
During render time povray threw an error:
Speicherzugriffsfehler
Any takers?
povray --version
POV-Ray 3.7.1-beta.2.unofficial
This is an unofficial version compiled by:
ThH <no.spam@address>
The POV-Ray Team is not responsible for supporting this version.
Copyright 1991-2017 Persistence of Vision Raytracer Pty. Ltd.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built-in features:
I/O restrictions: enabled
X Window display: enabled (using SDL)
Supported image formats: gif tga iff ppm pgm hdr png jpeg tiff openexr
Unsupported image formats: -
Compilation settings:
Build architecture: x86_64-unknown-linux-gnu
Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
Compiler vendor: gnu
Compiler version: g++ 4.9.2
Compiler flags: -pipe -Wno-multichar -Wno-write-strings
-fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math
-march=native -pthread
--
Thorsten aka ThH
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.02.2017 um 11:17 schrieb ThH:
> Rendering some old files I had an error with attractor.pov (source
> p.t.s-f, 20.08.2008, 'Attractor include and demo', Author: Rob)
>
> During render time povray threw an error:
> Speicherzugriffsfehler
>
> Any takers?
How much memory do you have available?
In his original post, Rob recommended at least 2GB, which to me
indicates that this scene might be particularly memory-hungry.
Also, which of the attractor examples are you trying to render?
With the first example from the originally posted scene (`clifford
(1.6,1.9, ...)`), I can't see anything wrong when using the Windows
version of POV-Ray.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/03/2017 05:17 AM, ThH wrote:
> Rendering some old files I had an error with attractor.pov (source
> p.t.s-f, 20.08.2008, 'Attractor include and demo', Author: Rob)
>
> During render time povray threw an error:
> Speicherzugriffsfehler
>
> Any takers?
>
> povray --version
>
> POV-Ray 3.7.1-beta.2.unofficial
>
> This is an unofficial version compiled by:
> ThH <no.spam@address>
> The POV-Ray Team is not responsible for supporting this version.
>
> Copyright 1991-2017 Persistence of Vision Raytracer Pty. Ltd.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Built-in features:
> I/O restrictions: enabled
> X Window display: enabled (using SDL)
> Supported image formats: gif tga iff ppm pgm hdr png jpeg tiff openexr
> Unsupported image formats: -
>
> Compilation settings:
> Build architecture: x86_64-unknown-linux-gnu
> Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
> Compiler vendor: gnu
> Compiler version: g++ 4.9.2
> Compiler flags: -pipe -Wno-multichar -Wno-write-strings
> -fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math
> -march=native -pthread
>
On Ubuntu 16.04 (Boost 1.58) tracked the seg fault to commit: 756cba6
Sun Jan 31 00:32:25 2016 +0100
"Added support for increased thread stack sizes when boost 1.50 or later
is used."
Was about to try bumping up the requested thread stack sizes some.
Wondering some about the change on linux where I think the commit above
means we moved from whatever was being set with the 'official' boost
package to something hard coded in povray. At least if I'm following the
change and understanding the windows vs linux boost set up correctly?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.02.2017 um 15:50 schrieb clipka:
> How much memory do you have available?
4GB
> Also, which of the attractor examples are you trying to render?
No. 1
--
Thorsten aka ThH
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/03/2017 10:05 AM, William F Pokorny wrote:
> On 02/03/2017 05:17 AM, ThH wrote:
>
> On Ubuntu 16.04 (Boost 1.58) tracked the seg fault to commit: 756cba6
> Sun Jan 31 00:32:25 2016 +0100
>
> "Added support for increased thread stack sizes when boost 1.50 or later
> is used."
>
> Was about to try bumping up the requested thread stack sizes some.
>
Working in commit
it seems like changing:
taskThread = NewBoostThread(boost::bind(&Task::TaskThread, this,
completion), 1024 * 1024 * 2);
to:
taskThread = NewBoostThread(boost::bind(&Task::TaskThread, this,
completion), 1024 * 1024 * 4);
in source/backend/support/task.cpp
gets past the seg fault. Let me see if the same change fixes our master
at 3.7.2... It does.
As for a real fix, not sure the path we should take?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.02.2017 um 16:26 schrieb William F Pokorny:
> On 02/03/2017 10:05 AM, William F Pokorny wrote:
>> On 02/03/2017 05:17 AM, ThH wrote:
>>
>> On Ubuntu 16.04 (Boost 1.58) tracked the seg fault to commit: 756cba6
>> Sun Jan 31 00:32:25 2016 +0100
>>
>> "Added support for increased thread stack sizes when boost 1.50 or later
>> is used."
>>
>> Was about to try bumping up the requested thread stack sizes some.
>>
>
> Working in commit
>
> it seems like changing:
>
> taskThread = NewBoostThread(boost::bind(&Task::TaskThread, this,
> completion), 1024 * 1024 * 2);
>
> to:
>
> taskThread = NewBoostThread(boost::bind(&Task::TaskThread, this,
> completion), 1024 * 1024 * 4);
>
> in source/backend/support/task.cpp
>
> gets past the seg fault. Let me see if the same change fixes our master
> at 3.7.2... It does.
>
> As for a real fix, not sure the path we should take?
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 :)
--
Thorsten aka ThH
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.02.2017 um 15:49 schrieb William F Pokorny:
> 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.
Done.
This problem is solved. Thank you Bill :)
> Normally other ways to do this define/override, but suppose the above
> change is our likely fix for unix - if it works for you.
It does.
> 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?
Yes. AMD Quadcore 64bit with 4GB Ram :)
> We suspect larger stacks might be needed for the 64 bit pointers in the
> stack frames.
>
> Thanks,
> Bill P.
--
Thorsten aka ThH
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.02.2017 um 16:40 schrieb ThH:
>> Normally other ways to do this define/override, but suppose the above
>> change is our likely fix for unix - if it works for you.
>
> It does.
I think at this point we should stop cranking up the stack size (as I
mentioned earlier, it will /always/ be possible to construct a scene
that breaks it), and think of a more adaptive solution, such as
providing an INI-file parameter to override the stack size.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
