I have a scene that is causing a segmentation fault

This is on Fedora linux 18 with an AMD Phenom II 980 quad core cpu
this system has 16gb of RAM

the compile is modified to increase the Fixed Simple Vector limits

i made the following changes to source/backend/frame.h
---------------------
// these defines affect the maximum size of some types based on
FixedSimpleVector

#ifndef MEDIA_VECTOR_SIZE
#define MEDIA_VECTOR_SIZE               12288
#endif

#ifndef MEDIA_INTERVAL_VECTOR_SIZE
#define MEDIA_INTERVAL_VECTOR_SIZE      12288
#endif

#ifndef LIT_INTERVAL_VECTOR_SIZE
#define LIT_INTERVAL_VECTOR_SIZE        12288
#endif

#ifndef LIGHT_INTERSECTION_VECTOR_SIZE
#define LIGHT_INTERSECTION_VECTOR_SIZE  12288
#endif

#ifndef LIGHTSOURCE_VECTOR_SIZE
#define LIGHTSOURCE_VECTOR_SIZE         12288
#endif

#ifndef WEIGHTEDTEXTURE_VECTOR_SIZE
#define WEIGHTEDTEXTURE_VECTOR_SIZE     12288
#endif

#ifndef RAYINTERIOR_VECTOR_SIZE
#define RAYINTERIOR_VECTOR_SIZE         12288
#endif

----------------


This is the output from povray while being run by the gdb debugger


Support libraries used by POV-Ray:
  ZLib 1.2.7, Copyright 1995-2012 Jean-loup Gailly and Mark Adler
  LibPNG 1.5.13, Copyright 1998-2012 Glenn Randers-Pehrson
  LibJPEG 62, Copyright 1991-2013 Thomas G. Lane, Guido Vollbeding
  LibTIFF 4.0.3, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
  Boost 1.50, http://www.boost.org/
  OpenEXR, Copyright (c) 2004-2007, Industrial Light & Magic.


Parser Options
  Input file: church.pov
  Remove bounds........On
  Split unions.........Off
  Library paths:
    /usr/local/share/povray-3.7
    /usr/local/share/povray-3.7/ini
    /usr/local/share/povray-3.7/include
    /data/MyPOV/objects
  Clock value:    0.000  (Animation off)
Image Output Options
  Image resolution.....1280 by 1024 (rows 1 to 1024, columns 1 to 1280).
  Output file..........church.png, 24 bpp PNG
  Dithering............Off
  Graphic display......Off
  Mosaic preview.......Off
  Continued trace......On
Information Output Options
  All Streams to console..........On
  Debug Stream to console.........On
  Fatal Stream to console.........On
  Render Stream to console........On
  Statistics Stream to console....On
[New Thread 0x7ffff4c26700 (LWP 11770)]
  Warning Stream to console.......On
==== [Parsing...] ==========================================================
[New Thread 0x7fffe7fff700 (LWP 11771)]
File 'church.pov' line 29: Parse Warning: See notes in glass_old.inc regarding
 use of this deprecated texture: T_Glass1
File 'church.pov' line 30: Parse Warning: See notes in glass_old.inc regarding
 use of this deprecated texture: T_Glass3
Parsing 64855K tokens
trees planted
Parsing 97008K tokens

 592 ornaments placed
Parsing 97233K tokens
lights placed
Parsing 118672K tokens

 592 ornaments placed
Parsing 119000K tokens
lights placed
Parsing 128123K tokens
xmas trees planted
church built
[Thread 0x7fffe7fff700 (LWP 11771) exited]
[New Thread 0x7fffe7fff700 (LWP 11792)]
[Thread 0x7fffe7fff700 (LWP 11792) exited]
----------------------------------------------------------------------------
Parser Statistics
----------------------------------------------------------------------------
Finite Objects:      1108270
Infinite Objects:          2
Light Sources:          1956
Total:               1110228
----------------------------------------------------------------------------
Parser Time
  Parse Time:       0 hours  2 minutes 21 seconds (141.900 seconds)
              using 1 thread(s) with 111.523 CPU-seconds total
  Bounding Time:    0 hours  0 minutes  6 seconds (6.009 seconds)
              using 1 thread(s) with 5.969 CPU-seconds total
[New Thread 0x7fffe7fff700 (LWP 11794)]
----------------------------------------------------------------------------
Render Options
  Quality:  9
  Bounding boxes.......On   Bounding threshold: 3
  Antialiasing.........On  (Method 1, Threshold 0.300, Depth 3, Jitter 1.00,
 Gamma 2.50)
[New Thread 0x7fff3bfff700 (LWP 11795)]
[New Thread 0x7fff3b7fe700 (LWP 11796)]
[New Thread 0x7fff3affd700 (LWP 11797)]
==== [Rendering...] ========================================================
[New Thread 0x7fff3a7fc700 (LWP 11798)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff3a7fc700 (LWP 11798)]
pov::Trace::ComputeShadowColour (this=this@entry=0x7fffed60b890,
lightsource=..., isect=...,
    lightsourceray=..., colour=..., ticket=...) at render/trace.cpp:2269
2269    {
(gdb)

This is the line in source/backend/render/trace.cpp


// see filter_shadow_ray in version 3.6's lighting.cpp
void Trace::ComputeShadowColour(const LightSource &lightsource, Intersection&
isect, Ray& lightsourceray, RGBColour& colour, TraceTicket& ticket)
{
 WeightedTextureVector wtextures;

This was a contiued trace that has gotted about 50% through the render. the
partial render took several days to get that far.

I was able to run a similar scene in RC6. the main difference there was
increasing the size of the trees outside from 180 to 240  pov units.

i will post a copy of that output in povray.binaries.images


the scene files weigh in at over 200 mb so I have not finished creating a
minimal scene yet.

any advice would be appreciated.

Thank you

Richard

Post a reply to this message

Le 02/03/2013 03:46, RM nous fit lire :
> I have a scene that is causing a segmentation fault
> 
> This is on Fedora linux 18 with an AMD Phenom II 980 quad core cpu
> this system has 16gb of RAM
> 
> the compile is modified to increase the Fixed Simple Vector limits

you might have a simple issue of stack size (where every calls get
stacked), and the line might be irrelevant.

Or instead of gdb, you might try valgrind for the default memcheck tool.
(but it slow the think by about 50 or 100 factors)
(Intel has nice inspector tools too, but they are a bit painful to set
up, and the license might or not allow them to you for free)

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 02/03/2013 03:46, RM nous fit lire :
> > I have a scene that is causing a segmentation fault
> >
> > This is on Fedora linux 18 with an AMD Phenom II 980 quad core cpu
> > this system has 16gb of RAM
> >
> > the compile is modified to increase the Fixed Simple Vector limits
>
> you might have a simple issue of stack size (where every calls get
> stacked), and the line might be irrelevant.
>
> Or instead of gdb, you might try valgrind for the default memcheck tool.
> (but it slow the think by about 50 or 100 factors)
> (Intel has nice inspector tools too, but they are a bit painful to set
> up, and the license might or not allow them to you for free

I am running the program using valgrind now to see what happens.

how do I increase the stack size?

Thanks

Richard

Post a reply to this message

RM <ric### [at] gmailcom> wrote:


> 
> I am running the program using valgrind now to see what happens.
> 
> how do I increase the stack size?
in thread.cpp in function:
void thread::start_thread()
{
}
you can modify pthread_create() to add a custom stacksize.

yvo



-- 
-----------------------------------
MegaPOV at:  http://megapov.inetart.net
MacMegaPOV at:  http://users.skynet.be/smellenbergh
E-mail: yvo(DOT)s(AT)gmx.net

Post a reply to this message

the only thread.cpp file i found was for boost.


is that the one you are talking about?

i dont wish to recompile boost to fix this because of the way fedora updates
packages. it would go away once an update was done to boost.


is there a way to only affect the stack size for povray?
is there a runtime parameter or something that can be specified for it at
compile time?

Thanks

Richard

Post a reply to this message

RM <ric### [at] gmailcom> wrote:

> the only thread.cpp file i found was for boost.
That is the one.

> i dont wish to recompile boost to fix this because of the way fedora updates
> packages. it would go away once an update was done to boost.
There are only a few files you need to compile from boost for PovRay.
Why don't you include them when you compile and ignore the fedora
package of boost?
For boost 1.45 you only have to compile the following files. If you use
later versions you need extra files but v 1.45 is fine.
 /libs/thread/src/tss_null.cpp
/libs/thread/src/pthread/thread.cpp << add stack fix in this one
/libs/thread/src/pthread/once.cpp

/libs/date_time/src/posix_time_types.cpp
I don't know if you need these but I use them somewhere in my Mac
compile:
/libs/date_time/src/gregorian/date_generators.cpp
/libs/date_time/src/gregorian/greg_month.cpp
/libs/date_time/src/gregorian/greg_weekday.cpp
/libs/date_time/src/gregorian/gregorian_types.cpp

 
> is there a way to only affect the stack size for povray?
> is there a runtime parameter or something that can be specified for it at
> compile time?
No, once there was a fix for this in a patched boost lib used by PovRay
but then you also had to compile it with the whole package to use it.

Yvo


-- 
-----------------------------------
MegaPOV at:  http://megapov.inetart.net
MacMegaPOV at:  http://users.skynet.be/smellenbergh
E-mail: yvo(DOT)s(AT)gmx.net

Post a reply to this message

I found that by using

 ulimit -s 16384

in bash prior to running  povray i could increase the stack size from the
default of 8192k to 16384k per thread.

this appears to be working and the render has been running for the last several
hours and making good progress.

Thanks for the advice Yvo, I will keep it in mind for future reference. I am not
comfortable enough with c++ yet to do that level of tinkering. doing the manual
compile of povray is my first experience with c++.

Richard

Post a reply to this message