 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I experience segfaults when trying to render the balcony.pov sample scene with
what would be the beta.30-rad1 for Linux (which unfortunately isn't published
yet).
There seems to be something weird going on related to the radiosity statistics
code.
Can someone with spare computing power and enough time at hand please force-test
this scene on Windows, to see whether it may suffer from any similar problems at
least occasionally?
Unfortunately I can't debug on Linux.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> I experience segfaults when trying to render the balcony.pov sample scene with
> what would be the beta.30-rad1 for Linux (which unfortunately isn't published
> yet).
>
> There seems to be something weird going on related to the radiosity statistics
> code.
>
> Can someone with spare computing power and enough time at hand please force-test
> this scene on Windows, to see whether it may suffer from any similar problems at
> least occasionally?
>
> Unfortunately I can't debug on Linux.
Additional note: I just tried to narrow down the error cause, only to find
deliberate code changes to affect the outcome in the weirdest of ways. I did
find that disabling a certain statistics counter would prevent the segfault;
but when examining *why* that was the case, and trying mark pixels on screen
for which a certain safety check would fail, I found that I could turn the
segfault on or off by nothing more than changing the "marker color".
To cut a long story short: This looks like a typical "wild pointer" to me, so
the underlying error could be *anywhere* in the code.
As balcony.pov is the only of the sample scenes where I have been getting
segfaults on a regular basis, I currently presume it has something to do with
media or photons. But even that is just a wild guess.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> I experience segfaults when trying to render the balcony.pov sample scene with
> what would be the beta.30-rad1 for Linux (which unfortunately isn't published
> yet).
Yet another additional note:
When running on 4 cores, The segfault invariably occurs at about 68% into the
final trace. That's roughly where the right leg of the table comes into view
below the tablecloth; it doesn't say much however about the exact location of
the problematic feature: The segfault could be related to a feature in a
slow-rendering square.
However, we can expect the problematic feature to be not too far away; what
catches my eye right away are the items on the table - which use photon
mapping.
(Running POV in single-thread mode might allow to pinpoint the location of the
problematic feature to a 32x32 square; unfortunately I haven't been able to get
it to segfault yet... well, actually I did get it to segfault before, but I
discarded the logfile before thinking about this, and at the moment I'm running
slightly different code which doesn't seem to segfault single-threaded.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> To cut a long story short: This looks like a typical "wild pointer" to me, so
> the underlying error could be *anywhere* in the code.
Linux? Sounds like a job for valgrind, but I don't know if that's practical for
something this large. I used it yesterday. A bad pointer started causing
problems in a completely unrelated spot. Took a couple minutes to solve with
valgrind.
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"triple_r" <nomail@nomail> wrote:
> Sounds like a job for valgrind, but I don't know if that's practical for
> something this large. I used it yesterday. A bad pointer started causing
> problems in a completely unrelated spot. Took a couple minutes to solve with
> valgrind.
I have no experience whatsoever with that tool. What does it do? Is it easy to
use? I'm not developing on Linux, I just compile and run my code on it for
performance and render quality evaluation (my QuadCore happens to run Linux,
and having POV crunch away systematically on a bunch of ~30 standard scenes is
a piece of cake with a few shell scripts; doing the same on my Windows XP P4
and still trying to do other stuff besides would be a PITA ;)).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> "triple_r" <nomail@nomail> wrote:
> > Sounds like a job for valgrind, but I don't know if that's practical for
> > something this large. I used it yesterday. A bad pointer started causing
> > problems in a completely unrelated spot. Took a couple minutes to solve with
> > valgrind.
I actually did it. Surprisingly easy to use, at least the memcheck part.
So far, it has only complained about some problems in the frontend, mostly
conditional jumps based on allegedly uninitialized values in standard C string
functions; I guess these are all false alarms due to optimizations in the
statically linked libs.
However, the jury is still out. It does slow down render considerably, and the
simulated multithreading does not help with this either ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> I have no experience whatsoever with that tool. What does it do? Is it easy to
> use? I'm not developing on Linux, I just compile and run my code on it for
> performance and render quality evaluation
valgrind works best if you compile with debug information (-g) and
without optimizations, because then if a problem happens it can tell
you the exact line where it did. Without debug information it can only
tell you the place with more or less accuracy, depending on how the
compiler generated the code. Optimizations can also mess things up
(because optimizations tend to remove code, inline code, move code
around, and all sort of stuff which is not nice when debugging).
OTOH sometimes such an error does not happen in debug mode but only
when full optimizations are used. Sometimes it's the optimizations which
make the problem reveal itself. (It's not like the debug version is
bug-free. It's just that the code happens to be generated in such way
that the error doesn't manifest itself as a segfault.)
So first try to compile with debug information and without optimizations,
and try to find the fastest possible way of causing the segfault. Then
just run valgrind giving it your command as parameter.
As you probably noticed, valgrind makes the program run very slow,
which is why you should try to find the fastest possible situation
which causes the segfault, unless you want to wait a few days for
valgrind to do its job.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> "clipka" <nomail@nomail> wrote:
> > I experience segfaults when trying to render the balcony.pov sample scene with
> > what would be the beta.30-rad1 for Linux (which unfortunately isn't published
> > yet).
>
> Yet another additional note:
>
> When running on 4 cores, The segfault invariably occurs at about 68% into the
> final trace. That's roughly where the right leg of the table comes into view
> below the tablecloth; it doesn't say much however about the exact location of
> the problematic feature: The segfault could be related to a feature in a
> slow-rendering square.
>
> However, we can expect the problematic feature to be not too far away; what
> catches my eye right away are the items on the table - which use photon
> mapping.
>
> (Running POV in single-thread mode might allow to pinpoint the location of the
> problematic feature to a 32x32 square; unfortunately I haven't been able to get
> it to segfault yet... well, actually I did get it to segfault before, but I
> discarded the logfile before thinking about this, and at the moment I'm running
> slightly different code which doesn't seem to segfault single-threaded.)
Work here (with some patches posted on this forum about missing headers):
~/bin/povray -w600 -h800 +a0.3 balcony.pov
==== [Rendering...] ========================================================
Rendered 480000 of 480000 pixels (100%)1369 pixels (92%)
----------------------------------------------------------------------------
Render Statistics
Image Resolution 600 x 800
----------------------------------------------------------------------------
Pixels: 520438 Samples: 1009638 Smpls/Pxl: 1.94
Rays: 8689094 Saved: 73221 Max Level: 15/15
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Box 38108326 7086401 18.60
Cone/Cylinder 25201563 7811008 30.99
CSG Intersection 26250463 4233964 16.13
CSG Merge 4073047 2148205 52.74
CSG Union 2683481 364287 13.58
Height Field 2361120 377505 15.99
Height Field Box 2361120 2316288 98.10
Height Field Triangle 9949624 401010 4.03
Height Field Block 10484599 3085837 29.43
Height Field Cell 32724633 5274428 16.12
Isosurface 5095537 680201 13.35
Isosurface Container 5113550 5113313 100.00
Isosurface Cache 779879 77790 9.97
Mesh 5243230 746253 14.23
Plane 71584938 16822081 23.50
Sphere 9680750 7800259 80.57
Torus 14372278 1000488 6.96
Torus Bound 14372278 1195715 8.32
Bounding Box 963390087 301050865 31.25
----------------------------------------------------------------------------
Isosurface roots: 5090612
Function VM calls: 58457879
----------------------------------------------------------------------------
Roots tested: 1195715 eliminated: 467417
Shadow Ray Tests: 25295819 Succeeded: 5491122
Shadow Cache Hits: 3400666
Reflected Rays: 1145669 Total Internal: 9270
Refracted Rays: 1008717
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Render Time:
Photon Time: 0 hours 0 minutes 0 seconds (0.251 seconds)
using 11 thread(s) with 0.844 CPU-seconds total
Radiosity Time: 0 hours 0 minutes 6 seconds (6.699 seconds)
using 8 thread(s) with 36.249 CPU-seconds total
Trace Time: 0 hours 1 minutes 29 seconds (89.724 seconds)
using 8 thread(s) with 494.350 CPU-seconds total
POV-Ray finished
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka escreveu:
> I'm not developing on Linux, I just compile and run my code on it for
> performance and render quality evaluation (my QuadCore happens to run Linux,
> and having POV crunch away systematically on a bunch of ~30 standard scenes is
> a piece of cake with a few shell scripts; doing the same on my Windows XP P4
> and still trying to do other stuff besides would be a PITA ;)).
Hah, so that's why you either don't know about gdb or don't want to use
it for debugging... ;)
and yes, same as for valgrind: compile with the -g switch...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmail com> wrote:
> Hah, so that's why you either don't know about gdb or don't want to use
> it for debugging... ;)
I have, basically, not the slightest idea about how to debug on Linux. I just
picture that, judging from popular Linux-jockey tools like vi and such, it
might be VERY far from trivial to get going... something like good old DOS
"debug" comes to my mind - me no want ;)
I also overheard work colleagues who were faced with the new challenge of
embedded Linux development (many having no Linux experience whatsoever), and
complained in particular about the lack of good debugging tools suitable for
"Windows-compatible" brains.
(Then again, I was somewhat surprised about ease of use with valgrind...
although unfortunately it didn't encounter the segfault, nor print any warning
at ~68% (it's at 72% right now); looks like it is subject to rare
coincidences.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
