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