Le Forgeron <jgr### [at] freefr> wrote:
> Le Sat, 06 Sep 2008 06:44:24 -0400, geep999 a modifié des petits morceaux

>
> >> > If anybody get a clue, please share...

Another tidbit...

I have a workaround for the segfault on m_textures.ini. Details appended
below...

Ran povray with DUMA - Detect Unintended Memory Access -
http://duma.sourceforge.net/
DUMA pointed to this line of code: render/trace.cpp:1611
I ran this several times and the segfault always occurred here.
Simlar result with scenes/advanced/wineglass.pov
The previous inconsistent segfaults aren't present running with DUMA.

Doing a kompare of trace.cpp between beta28 and beta25b it is easy to see how
the block of code around line 1611 has been changed.
I reverted this block of code to the beta25 version, et voila, no more crashes.

The 14 .png files produced by m_textures.ini look the same as from beta25.

Would be interested if mon ami Le Forgeron can replicate this workaround.

Hope this isn't a red herring, as I admit that I don't know the functionality of
the code I reverted and any unintended consequences.

Salutations,
Peter

0/ D.U.M.A. - Detect Unintended Memory Access http://duma.sourceforge.net/

1/ I followed these instructions which are extracted from DUMA's README.txt...

You can also use dynamic linking. If you're using a Bourne shell, the statement
'export LD_PRELOAD=libduma.so.0.0' will cause DUMA to be loaded to run all
dynamic executables

CATCHING THE ERRONEOUS LINE:

1. Compile your program (with debugging information) without DUMA.
2. Set 'ulimit -c unlimited' to get core files
3. Start your program, choose one of following options
   a) Start your program (linked statically with DUMA)
   b) Start your program with duma.sh <your_program>
4. Wait for a segmentation fault. this should have created a core[.<pid>]
   file. You can get into a debugger f.e. with 'gdb <program> -c <core file>'


2/ Installed DUMA and copied the file duma.sh into the directory containing
m_textures.ini

sudo sysctl -w vm.max_map_count=1000000
ulimit -c unlimited
export LD_PRELOAD=libduma.so.0.0

../duma.sh povray m_textures.ini +Q11

../duma.sh: line 17: 30426 Segmentation fault      (core dumped) ( export
LD_PRELOAD=libduma.so.0.0.0; export DYLD_INSERT_LIBRARIES=libduma.dylib; export
DYLD_FORCE_FLAT_NAMESPACE=1; exec $* )

gdb povray -c core.30426

Stacktrace messages ended with:
Core was generated by `povray m_textures.ini +Q11'.
Program terminated with signal 11, Segmentation fault.
#0  0x0819b5c6 in pov::Trace::ComputeOneDiffuseLight (this=0xae5134c4,
lightsource=0xae3adec0, reye=@0xad91e560, finish=0xaf1a8f8c,
ipoint=@0xad91e98c, eye=@0xad91f20c, layer_normal=@0xad91ea68,
    layer_pigment_colour=@0xad91ea28, colour=@0xad91e9d8,
attenuation=0.30000001192092896, object=0xaf198f6c, light_index=0) at
render/trace.cpp:1611
1611                                    lcc.tested = true;

......and from wineglass.pov too...
Core was generated by `povray wineglass.pov'.
Program terminated with signal 11, Segmentation fault.
#0  0x0819b5c6 in pov::Trace::ComputeOneDiffuseLight (this=0xaa1bf4c4,
lightsource=0xaa219ec0, reye=@0xa9cb98f0, finish=0xaaf09f8c,
ipoint=@0xa9cb9d1c, eye=@0xa9cba5b4, layer_normal=@0xa9cb9df8,
    layer_pigment_colour=@0xa9cb9db8, colour=@0xa9cb9d68,
attenuation=0.050000011920928955, object=0xaaefbf48, light_index=0) at
render/trace.cpp:1611
1611                                    lcc.tested = true;

Source Code...

beta28 source/backend/render/trace.cpp
1601 // If light source was not blocked by any intervening object, then
1602 // calculate it's contribution to the object's overall illumination.
1603 if ((qualityFlags & Q_SHADOW) && ((lightsource->Projected_Through_Object !=
NULL) || (lightsource->Light_Type != FILL_LIGHT_SOURCE)))
1604 {
1605  if (lightColorCacheIndex != -1 && light_index != -1)
1606  {
1607   LightColorCache& lcc(lightColorCache[lightColorCacheIndex][light_index]);
1608   if (lcc.tested == false)
1609   {
1610    TraceShadowRay(lightsource, lightsourcedepth, lightsourceray, eye,
ipoint, lightcolour);
1611    lcc.tested = true;
1612    lcc.colour = lightcolour;
1613   }
1614   else
1615    lightcolour = lcc.colour;
1616  }
1617  else
1618   TraceShadowRay(lightsource, lightsourcedepth, lightsourceray, eye,
ipoint, lightcolour);
1619 }

beta25b source/backend/render/trace.cpp
1581 // If light source was not blocked by any intervening object, then
1582 // calculate it's contribution to the object's overall illumination.
1583 if((qualityFlags & Q_SHADOW) && ((lightsource->Projected_Through_Object !=
NULL) || (lightsource->Light_Type != FILL_LIGHT_SOURCE)))
1584  TraceShadowRay(lightsource, lightsourcedepth, lightsourceray, eye, ipoint,
lightcolour);

Post a reply to this message

> beta28 source/backend/render/trace.cpp
> 1601 // If light source was not blocked by any intervening object, then
> 1602 // calculate it's contribution to the object's overall illumination.
> 1603 if ((qualityFlags & Q_SHADOW) && ((lightsource->Projected_Through_Object !=
> NULL) || (lightsource->Light_Type != FILL_LIGHT_SOURCE)))
> 1604 {
> 1605  if (lightColorCacheIndex != -1 && light_index != -1)
> 1606  {
> 1607   LightColorCache& lcc(lightColorCache[lightColorCacheIndex][light_index]);
> 1608   if (lcc.tested == false)
> 1609   {
> 1610    TraceShadowRay(lightsource, lightsourcedepth, lightsourceray, eye,
> ipoint, lightcolour);
> 1611    lcc.tested = true;
> 1612    lcc.colour = lightcolour;
> 1613   }
> 1614   else
> 1615    lightcolour = lcc.colour;
> 1616  }
> 1617  else
> 1618   TraceShadowRay(lightsource, lightsourcedepth, lightsourceray, eye,
> ipoint, lightcolour);
> 1619 }

	FWIW lately I've been investigating that very portion of code as the possible
cause for the reported crash, since light color cache for textures were re-introduced
in the most recent beta.  Your investigation seems to confirm my guess.  However,
so far and due to limited time, I did not manage to identify/understand why this
particular and related code may cause a segfault; e.g. lightColorCacheIndex and
light_index were in my tests never < -1 or too large when indexing the allocated
tables.

	Chris: any idea what could be wrong in here?

	- NC

Post a reply to this message

Le Mon, 15 Sep 2008 18:58:34 -0400, geep999 a modifié des petits morceaux
de l'univers pour nous faire lire :

> Le Forgeron <jgr### [at] freefr> wrote:
>> Le Sat, 06 Sep 2008 06:44:24 -0400, geep999 a modifié des petits
>> morceaux de l'univers pour nous faire lire :
>>
>> >> > If anybody get a clue, please share...
> 
> Another tidbit...
> 
> I have a workaround for the segfault on m_textures.ini. Details appended
> below...
> 
> Doing a kompare of trace.cpp between beta28 and beta25b it is easy to
> see how the block of code around line 1611 has been changed. I reverted
> this block of code to the beta25 version, et voila, no more crashes.
> 

Yes... once you have isolated trace.cpp, it is "easy"... congratulation
for that finding.


> The 14 .png files produced by m_textures.ini look the same as from
> beta25.
> 
> Would be interested if mon ami Le Forgeron can replicate this
> workaround.

I do. I do.
You are just removing the lightColourCache by the way.

and it's not perfect, I still get a memory fault for: 
-Q0
-Q1

things are ok for all higher Q (previously 0, 1 & 6+ was crashing)

> 
> Hope this isn't a red herring, as I admit that I don't know the
> functionality of the code I reverted and any unintended consequences.

Caching is the functionality you are just dropping... I'm not sure how 
Chris will react to this idea.

I'm wondering, with the fact that the previous analysis show that the 
issue was *always* encountered at the start of the rendering, if the 
cache is still in its creation phase (including many resize call ?) 
somewhere while another thread try already to use it ? (unleashing the 
mongolian hord too early on the data-block ???)
Removing the second user avoid the collision...

the removed code is about getting a reference (think shortcut for 
dereferenced pointer), then using it.
The fun part is that the reference is one of a very short structure, held 
into a vector of vector (Yes, it make my head a bit fuzzy, and i do not 
understand yet the two indexes).

two points:
 * there seems to be only code to resize one dimension, but not the 
other. May be it's ok. this cache is also use in the photon phase.
 * there is no protection on accessing this structure, and it is modified 
over a long time period (get in entering the "then" part, filled sometime 
after a ray tracing)

I still have to understand how this cache is supposed to work.
And this workaround does not work with -Q1 & -Q0, so there is something 
else still fishy.

Post a reply to this message

geep999 wrote:
> 1611                                    lcc.tested = true;

Good work in picking this up: looking at the code it's fairly clear what's
happening. Since the test (lcc.tested == false) isn't segfaulting but the
assignment is, the memory must have been freed during TraceShadowRay(). The
only thing that would cause that is a re-alloc of the cache via resize(),
which is exactly what's done in ComputeShadowColor().

Suggestion: as an experiment, try changing the initial value of the cache
(line 153) to a much larger value and see if the fault goes away. I suspect
it will (note this is not the solution, just a test: the solution is to
either avoid the need to resize, or to not keep references to the data
across calls to the trace functions).

-- Chris

Post a reply to this message

NB I suspect that initializing it as such:

  lightColorCache.resize(sd->parsedMaxTraceLevel + 1)

should be sufficient. If I can ensure that it should never go above that
value then I ought to replace the resize with an exception.

-- Chris

Post a reply to this message

Le Thu, 18 Sep 2008 21:22:18 +1000, Chris Cason a modifié des petits
morceaux de l'univers pour nous faire lire :


> Suggestion: as an experiment, try changing the initial value of the
> cache (line 153) to a much larger value and see if the fault goes away.
> I suspect it will (note this is not the solution, just a test: the
> solution is to either avoid the need to resize, or to not keep
> references to the data across calls to the trace functions).
> 

It is far better (tried with a huge modifier of 10* ).
No more segfaults there.

Looks like a very good point.

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> NB I suspect that initializing it as such:
>
>   lightColorCache.resize(sd->parsedMaxTraceLevel + 1)
>
> should be sufficient. If I can ensure that it should never go above that
> value then I ought to replace the resize with an exception.
>
> -- Chris

Line 153 changed to: lightColorCache.resize(sd->parsedMaxTraceLevel + 1);
works fine with m_textures.ini and wineglass.pov

Salutations,
Peter

Post a reply to this message

"geep999" <nomail@nomail> wrote:
> works fine with m_textures.ini and wineglass.pov
>
Not quite...
Confirming Le Forgeron's observation that there are still segfaults with povray
m_textures.ini +Q0 and +Q1
even with trace.cpp Line 153 changed to:
lightColorCache.resize(sd->parsedMaxTraceLevel + 1);

See below for duma and regular stacktraces.
Salutations, Peter

duma............................................
duma.sh povray m_textures.ini +Q0

.../duma.sh: line 17:  7890 Segmentation fault      (core dumped) ( export
LD_PRELOAD=libduma.so.0.0.0; export DYLD_INSERT_LIBRARIES=libduma.dylib; export
DYLD_FORCE_FLAT_NAMESPACE=1; exec $* )

gdb povray -c core.7890
.........
bt
Cannot access memory at address 0xb7f786c4
(gdb)
(gdb) bt
#0  0x0819d235 in pov::Trace::ComputeLightedTexture (this=Cannot access memory
at address 0xad5ab7c0
) at render/trace.cpp:920
Cannot access memory at address 0xad5ab7bc

gdb.............................................
gdb povray
run m_textures.ini +Q0
bt
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1271993456 (LWP 10009)]
0x0819d235 in pov::Trace::ComputeLightedTexture (this=0xb39917cc,
resultcolour=@0xb42edb70, texture=0x836b5b0,
    warps=@0x8311fb8, ipoint=@0xb42edb30, rawnormal=@0xb42edb48,
ray=@0xb42eddec, weight=1, isect=@0xb42edc98)
    at render/trace.cpp:920
920                                     filCol[pRED]   *= min(1.0, 1.0 -
listWNRX->back().reflec[pRED]);
(gdb) bt
#0  0x0819d235 in pov::Trace::ComputeLightedTexture (this=0xb39917cc,
resultcolour=@0xb42edb70, texture=0x836b5b0,
    warps=@0x8311fb8, ipoint=@0xb42edb30, rawnormal=@0xb42edb48,
ray=@0xb42eddec, weight=1, isect=@0xb42edc98)
    at render/trace.cpp:920
#1  0x08196f01 in pov::Trace::ComputeOneTextureColour (this=0xb39917cc,
resultcolour=@0xb42edb70, texture=0x836b5b0,
    warps=@0x8311fb8, ipoint=@0xb42edb30, rawnormal=@0xb42edb48,
ray=@0xb42eddec, weight=1, isect=@0xb42edc98,
    shadowflag=false, photonPass=false) at render/trace.cpp:600
#2  0x08198b6d in pov::Trace::ComputeTextureColour (this=0xb39917cc,
isect=@0xb42edc98, colour=@0xb42edfa4,
    ray=@0xb42eddec, weight=1, photonPass=false) at render/trace.cpp:532
#3  0x0819eb69 in pov::Trace::TraceRay (this=0xb39917cc, ray=@0xb42eddec,
colour=@0xb42edfa4, weight=1)
    at render/trace.cpp:216
#4  0x081b3097 in pov::TracePixel::operator() (this=0xb39917cc,
x=18.493499666452408, y=18.319661332915228, width=200,
    height=200, colour=@0xb42edfa4) at render/tracepixel.cpp:326
#5  0x081aa647 in pov::TraceTask::SupersampleOnePixel (this=0xb3991770, x=18,
y=18, col=@0x836e6d0)
    at render/tracetask.cpp:711
#6  0x081aa948 in pov::TraceTask::NonAdaptiveSupersamplingForOnePixel
(this=0xb3991770, x=18, y=18, leftcol=@0x836e6bc,
    topcol=@0x836e450, curcol=@0x836e6d0, sampleleft=@0xb42ee11f,
sampletop=@0xb42ee11e, samplecurrent=@0xb42ee11d)
    at render/tracetask.cpp:692
#7  0x081abe01 in pov::TraceTask::NonAdaptiveSupersamplingM1 (this=0xb3991770)
at render/tracetask.cpp:606
#8  0x081ac27b in pov::TraceTask::Run (this=0xb3991770) at
render/tracetask.cpp:339
#9  0x081b90f5 in pov::Task::TaskThread (this=0xb3991770, completion=@0x83127a4)
at support/task.cpp:233
#10 0x081ba2de in boost::_mfi::mf1<void, pov::Task, boost::function0<void,
std::allocator<boost::function_base> > const&>::operator() (this=0x8312798,
p=0xb3991770, a1=@0x83127a4) at /usr/include/boost/bind/mem_fn_template.hpp:149
#11 0x081ba36b in boost::_bi::list2<boost::_bi::value<pov::Task*>,
boost::_bi::value<boost::function0<void, std::allocator<boost::function_base> >
> >::operator()<boost::_mfi::mf1<void, pov::Task, boost::function0<void,
std::allocator<boost::function_base> > const&>, boost::_bi::list0>
(this=0x83127a0, f=@0x8312798, a=@0xb42ee307) at
/usr/include/boost/bind.hpp:286
#12 0x081ba3a8 in boost::_bi::bind_t<void, boost::_mfi::mf1<void, pov::Task,
boost::function0<void, std::allocator<boost::f---Type <return> to continue, or
q <return> to quit---
unction_base> > const&>, boost::_bi::list2<boost::_bi::value<pov::Task*>,
boost::_bi::value<boost::function0<void, std::allocator<boost::function_base> >
> > >::operator() (this=0x8312798) at
/usr/include/boost/bind/bind_template.hpp:20
#13 0x081ba3c5 in
boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void,
boost::_mfi::mf1<void, pov::Task, boost::function0<void,
std::allocator<boost::function_base> > const&>,
boost::_bi::list2<boost::_bi::value<pov::Task*>,
boost::_bi::value<boost::function0<void, std::allocator<boost::function_base> >
> > >, void>::invoke (function_obj_ptr=
      {obj_ptr = 0x8312798, const_obj_ptr = 0x8312798, func_ptr = 0x8312798,
data = "\230"})
    at /usr/include/boost/function/function_template.hpp:136
#14 0x081bae68 in boost::function0<void, std::allocator<boost::function_base>
>::operator() (this=0xb42ee390)
    at /usr/include/boost/function/function_template.hpp:576
#15 0xb7a0c7b2 in ?? () from /usr/lib/libboost_thread-mt.so.1.33.1
#16 0xb7e1f1b3 in start_thread () from /lib/libpthread.so.0
#17 0xb787c03e in clone () from /lib/libc.so.6

Post a reply to this message

geep999 wrote:
> Confirming Le Forgeron's observation that there are still segfaults with povray
> m_textures.ini +Q0 and +Q1

please change line 917 of trace.cpp to read -

  if(layer->Finish->Conserve_Energy != 0 && listWNRX->empty() == false)

and the above segfault should go away.

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> please change line 917 of trace.cpp to read -
>
>   if(layer->Finish->Conserve_Energy != 0 && listWNRX->empty() == false)
>
> and the above segfault should go away.
Confirmed it has gone away. Tested with +Q0 though +Q11
Salutations, Peter

Post a reply to this message