On 4/22/23 15:51, jr wrote:
> hi,
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> I get a segmentation fault with this scene:
>> ...
>> I used self-compiled POV-Ray 3.7.0.10 for Unix.  This code renders fine
>> with 3.8-beta 2, ...
> 
> yep, v3.7.0.8 on Debian 11/bullseye too segfaults.  though fine with beta.2,
> WFP's povr informs: "Check_Photon_Light_Group called and internal code is
> incomplete.Internal Error."
> 
> regards, jr.
> 

The issue here is: max_trace_level 255

 From our documentation:

Note: Raising max_trace_level will use more memory and time and it could 
cause the program to crash with a stack overflow error, although ADC 
will alleviate this to a large extent.

Aside 1: On the documentation the ADC bailout helps less with 
assumed_gamma 1, photons (and radiosity?). There is too a comment about 
a warning being issued if the max is hit, which I think not true. The 
Max Level: n/max usage is reported as information.


--- More
v3.7 still has the old unix/linux stack size allocation issues. Windows 
v3.7 does too, but it kicks in much later than g++ due how the window's 
build/compile works. One of our initial patches for the stack overflow 
issue doubled the default stack sizes if compiling on unix/linux...

That initial unix/linux 'patch/hack' was later deleted. Christoph put in 
a chunk of work to remove most (practically, perhaps all) stack size 
allocation issues in the v3.8 code & onward. I've not run into a stack 
overflow issue since his thread-stack handling changes were completed.

There are too compiler options which change stack overflow behavior and 
likely-hood. So, with the v3.7 code base, it's not too surprising we 
might be seeing differences in behavior depending upon the build. The 
linux package distribution folks compile with a more conservative set of 
flags than does the default POV-Ray release configure script.

Aside 2: IIRC there is a max_trace_level setting inside the photon block 
inside global_settings. I didn't play with it. Probably, it defaults to 
the scene's global setting unless overridden, but not sure. In my 
testing, if either radiosity or photons turned on, the segfault happened 
with max_trace_level at 255.

Aside 3: Shouldn't the light_source in the scene have a photon block too?

Aside 4: (Thanks jr!) The Internal error out of povr was me putting in a 
message to force myself to look at that hacked code a little more on the 
next photon scene I ran. I forgot it was sitting there in the code...

My thinking is we should not just return 'true' from that hacked 
function, but rather should run the loop which tests whether at least 
one light group source has photon block before returning true. But, the 
reality is there are other things not complete in the code with respect 
to photons and light groups. See: 
https://github.com/POV-Ray/povray/issues/126

Aside 4.5: The commented code in Check_Photon_Light_Group touches on 
that compile time configurable 'global' photon keyword mentioned during 
the work toward the povr word_is / word_get additions. The photon 
specific keyword 'global' was co-opted for use in v3.8 onward for the 
global dictionary. If the option is re-enabled, we'll likely need to 
change the photon keyword 'global' to something else.

Anyhow...

Bill P.

Post a reply to this message