I get a segmentation fault with this scene:

----------[BEGIN CODE]---------
// +W300 +H240
#version 3.7;

global_settings
{ assumed_gamma 1
  max_trace_level 255
  photons { spacing 0.05 media 100 }
  radiosity
  { count 200
    error_bound 0.5
    pretrace_end 1 / image_width
    pretrace_start 16 / image_width
    recursion_limit 2
  }
}

camera
{ orthographic
  location -10 * z
  right 10 * x
  up 8 * y
}

light_source { <-0.6, 1, -2> * 1000, rgb 1 parallel point_at 0 }
background { rgb 0.25 }

#default { finish { ambient 0.125 diffuse 0.75 } }

#declare v_Scale = <3, 3, 2>;

difference
{ sphere { 0, 1 scale v_Scale }
  sphere { 0, 1 scale v_Scale - 0.5 }
  pigment { rgbf 1 }
  finish
  { reflection { 0, 1 fresnel } conserve_energy
    specular albedo 0.05 roughness 0.001
  }
  interior
  { ior 1.51673
    fade_color <0, 0.8, 0.4>
    fade_power 1001
    fade_distance v_Scale.z / 2
  }
  photons { target refraction on reflection on collect off }
}

plane
{ -z, -v_Scale.z - 0.001
  pigment { checker rgb 0.5 rgb 1 scale 2 translate x }
}
-----------[END CODE]----------

I used self-compiled POV-Ray 3.7.0.10 for Unix.  This code renders fine
with 3.8-beta 2, and the scene description file from which this code was
extracted rendered to completion with 3.7-RC7 back in 2013, so something
happened between 3.7-RC7 and 3.7.0.10 that did not carry over into 3.8.

The code renders fine if I delete both the photons *and* the radiosity,
but if I include either one, the scene seg faults.

Does anyone else get a seg fault with their POV-Ray 3.7?  Does anyone
see any mistakes I may have made in the code?

POV-Ray versions: POV-Ray 3.7.0.10 (self-compiled)
Operating system: openSUSE Leap 15.3 GNU/Linux
Hardware: Lenovo Ideapad Slim 7
CPU: Intel Core i7

Post a reply to this message

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.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ...
> 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."

the Debian version is pre-compiled, 'apt' installed.  interestingly, on a
Slackware machine, self-compiled 3.7.0.8 and 3.7.1-rc.1 run ok, until I add a
'+q'uality switch higher than '8'.  :-)


regards, jr.

Post a reply to this message

(running official v3.7.0 msvc10.win64 at default Quality 9, Windows 10, Lenovo
desktop machine with Core I7, 8 cores/16 threads)

No segfault or other problems for me; the code runs fine. I tried it at various
render resolutions, with/without AA, and different Quality settings.
Render_Block_Size at default (32?). Bounding_Threshold=1.

Post a reply to this message

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