POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Tasklist

FS#50 - Frequent segfaults with photon scenes

Attached to Project: POV-Ray
Opened by Christoph Lipka (clipka) - Sunday, 23 August 2009, 06:22 GMT
Last edited by William F Pokorny (wfpokorny) - Friday, 21 October 2016, 14:40 GMT
Task Type Possible Bug
Category Platform-specific → Runtime error
Status Tracked on GitHub
Assigned To No-one
Operating System Linux
Severity Medium
Priority Normal
Reported Version 3.70 beta 32
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

I observe frequent segfaults with POV-Ray 3.7 betas when rendering scenes using photons:

  • Debian Linux 4.0r5 “etch” for AMD64
  • AMD Phenom X4 9650 2.3GHz, 6 GB RAM
  • POV-Ray compiled with Intel icpc 11.0

Segfaults are sporadic but frequent (occurring in roughly 50% of all photon renders).

This task depends upon

Comment by Christoph Lipka (clipka) - Saturday, 07 November 2009, 16:24 GMT

Segfaults also seen on Debian Linux 5.0.3 "Etch" using Intel icpc 11.1 compiler, with same frequency.

As I haven't yet observed any such segfaults with GNU g++ versions of POV-Ray on the same machine, I currently suspect issues introduced by automatic code optimization.

Comment by Christoph Lipka (clipka) - Wednesday, 23 June 2010, 10:52 GMT

Segfaults also seen on OpenSUSE 11.2 (x86_64), again using Intel icpc 11.1

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 22 August 2011, 20:56 GMT

Trying –benchmark with icpc (static) povray. (povray #5480, icpc 12.0.5 20110719, ubuntu 11.04, boost 1.47)

Found a difference in objects:

----------------------------------------------------------------------------
Parser Statistics
----------------------------------------------------------------------------
Finite Objects:          175
Infinite Objects:          3
Light Sources:             2
Total:                   180

whereas gcc povray

----------------------------------------------------------------------------
Parser Statistics
----------------------------------------------------------------------------
Finite Objects:          177
Infinite Objects:          1
Light Sources:             2
Total:                   180

As benchmark use photons, I fails to segfault (ran 4 times –benchmark, no segfault)

The ratio of bounding goes from 51.64 (gcc) to 30.25 (icpc)

Configuration of povray:
./configure COMPILED_BY="..." –disable-io-restrictions –with-boost-libdir=/opt/intel/lib –with-boost-thread=boost_thread –with-boost=/opt/intel CC="icc" CXX="icpc" –enable-static –disable-debug –enable-optimize

and LD_LIBRARY_PATH extended with /opt/intel/lib (where are libboost*.*)

Comment by Thorsten Fröhlich (thorsten) - Tuesday, 23 August 2011, 06:40 GMT

AFAIK there are changes / bug fixes in photon code in RC4. Has this problem been resolved?

Comment by Christoph Lipka (clipka) - Thursday, 25 August 2011, 12:41 GMT

@Jerome: Such a difference in number of objects shouldn't happen; are you sure you used the same source code?

Comment by Christoph Lipka (clipka) - Thursday, 25 August 2011, 15:59 GMT
AFAIK there are changes / bug fixes in photon code in RC4. Has this problem been resolved?
No, I still see segfaults with the current Perforce head (#5480)
Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 25 August 2011, 16:36 GMT

@Christoph: my last generation with icpc was done with the following configure (on a tree-copy of the smp sources, as extracted for my gnu-compile of smp, at #5480, with just a 3 changes (local/declare) in benchmark.cpp to be able to run it.)

(it is now dynamic link, allowing usage of SDL to view the render in progress)

(quotes added back from config.log)
$ ./configure COMPILED_BY="Jérôme Grimbert jgrimbert@free.fr" –disable-io-restrictions –with-boost-libdir=/opt/intel/lib –with-boost-thread=boost_thread –with-boost=/opt/intel CC=icc CXX=icpc –disable-debug

The total count of objects is the same, it's only the finite/infinite which are different. (but I do not know (yet ?) which ones)

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 25 August 2011, 16:50 GMT

I want to amend my object count: both smp (gnu & icpc) are reporting 175+3 ; only my experimental branch is reporting 177+1, so the problem is mine, all mine.
Do not waste time on that count. Sorry.

(Now, if you can provide a scene which fails with photons, so that I can try it also with icpc, that would be great)

Comment by Christoph Lipka (clipka) - Thursday, 25 August 2011, 17:03 GMT

Please try the following sample scenes:

advanced/balcony
advanced/diffuse_back.pov
advanced/optics.pov

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 25 August 2011, 17:44 GMT

Ran optics 4 times, diffuse 1, balcony twice... no problem.
My system : i7, 6 cores with hyperthreading (+WT12), 64 bits, linux ubuntu 11.04
icpc 12.0.5

$ file /usr/local/bin/povrayicpc
/usr/local/bin/povrayicpc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

Render Options

Quality:  9
Bounding boxes.......On   Bounding threshold: 3
Antialiasing.........On  (Method 1, Threshold 0.030, Depth 3, Jitter 1.00,

Gamma 2.50)

In ~/.povray/3.7/povray.ini
Verbose=Off
Display=On
Bounding_Threshold=3

Optics has a parse warning:
File 'optics.pov' line 32: Parse Warning: Camera location to look_at direction
and sky direction should be different. Using default/supplied right vector
instead.

@ Christoph : can you state the difference between your and my settings ?

Comment by Christoph Lipka (clipka) - Thursday, 25 August 2011, 18:33 GMT

My system: AMD Phenom X4, 4 cores, no HT (implicit +WT4), 64 bit, varying Linux distros (Debian 4.0r5 and 5.0.3, OpenSUSE 11.2
varying icpc versions (11.0, 11.1, 12.0.3)

povray: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.4, stripped

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 25 August 2011, 19:10 GMT

You're using icpc on a AMD ? Can't it be some differents implementation of op-codes (time & schedule) that become problematic ?
(well, how could we know ?)
Or some issue with the SSE level ?

Looking at icc flags: http://www.gentoo-wiki.info/HOWTO_ICC_and_Portage Did you try to also get some generic code (-axX (X:=(K,W,P,T,S) ) ?

It seems that: icc generates code that detects the brand of processor on which it is executing. On Intel CPUs, the binary will execute with SSE instructions, whereas it will execute 386 level instructions on AMD CPUs regardless of availability of SSE instruction sets.

If that's true, is there any interest to run icpc compiled povray on AMD ?

Comment by Christoph Lipka (clipka) - Thursday, 25 August 2011, 19:37 GMT

I suspect the information on that gentoo page might be outdated; at any rate I found the ICPC-compiled binaries to render a bit faster on average than the GCC-compiled ones, even on the Phenom X4 machine.

Comment by Thorsten Fröhlich (thorsten) - Thursday, 25 August 2011, 19:39 GMT

Yes, that information is outdated. IIRC it has been subject to legal action by AMD against Intel several years ago, and ICC optimizes for AMD just as well nowadays.

Comment by Thorsten Fröhlich (thorsten) - Thursday, 25 August 2011, 19:48 GMT Comment by Chris Cason (chrisc) - Tuesday, 04 September 2012, 22:51 GMT

Is this still an issue?

Comment by Christoph Lipka (clipka) - Wednesday, 05 September 2012, 15:20 GMT

Haven't tested lately, so I suspect it's still there. But as apparently I'm still the only one seeing this issue, I'd be ok with demoting the severity and priority.

Comment by William F Pokorny (wfpokorny) - Friday, 21 October 2016, 14:40 GMT
  • Field changed: Status (Unconfirmed → Tracked on GitHub)
  • Field changed: Severity (Critical → Medium)

Now tracked on github as issue #127.

Loading...