On 3/13/22 04:34, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ... It's one of those insidious subtle bugs that cause
>> confusing / hair pulling results when they do bite.
> 
> may have run into one those with 'povr' yesterday.  been using it while playing
> with the USaF (see p.b.a) code since it's quicker to render.  all ok for the 500
> frame tests, but when I went to do a "final" render, it crashed
> ("uncategorized", from memory) at the 3048th frame.  (sorry, bearer of bad news
> and all that)
> 
> 
> regards, jr.
> 

This with the Real_Time_Capture=true|false (+-rtc) capability for the 
real time rendering mode (.pfm output) or with traditional animation?

Is the fail easily repeatable?

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> This with the Real_Time_Capture=true|false (+-rtc) capability for the
> real time rendering mode (.pfm output) or with traditional animation?

regular animation, running from an ini.


> Is the fail easily repeatable?

not sure, happened late in the animation[*], had no stomach to try + repeat,
sorry.  the code in question is the 'usaf' animation posted same time (March
13th).

[*] as I wrote, I was v surprised because 'povr' run the (shorter) test segments
without hassle, and fast.


regards, jr.

Post a reply to this message

On 3/17/22 02:04, jr wrote:
>> Is the fail easily repeatable?
> not sure, happened late in the animation[*], had no stomach to try + repeat,
> sorry.  the code in question is the 'usaf' animation posted same time (March
> 13th).

No problem. The flaky issues / bugs are always the hard ones to run down.

Did you continue the animation successfully starting from frame 3048?
Or, is it an animation where each frame depends on information from 
previous frames(s) such that starting at frame 3048 not possible?

I might try running valgrind looking for memory leaks with your 
particular animation as a shot in the dark. But, that's not something 
I'll get to for a while.

Wondering too if the regular animation mechanisms can develop the memory 
bubbles seen with RTR. My guess is the frame rates with regular 
animation always too slow for it to happen - and as a light user of 
regular animation I've never noticed a (povms) memory bubble effect but, 
never gone looking for it, so who knows.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/17/22 02:04, jr wrote:
> >> Is the fail easily repeatable?
> > not sure, ...
> No problem. The flaky issues / bugs are always the hard ones to run down.

took copy of code posted + tried again, several times, every time the run (now)
crashes at frame 2800; have tried to remember which if any changes I made, but
can only think of quality + dimensions in ini file.  attached excerpt from
'povr' build-log, libraries in use, and the animation state at the time.



> Did you continue the animation successfully starting from frame 3048?
> Or, is it an animation where each frame depends on information from
> previous frames(s) such that starting at frame 3048 not possible?

no, did not.  simply switched to POV-Ray proper, wanted "it" (the anim) out of
my hair :-).


> I might try running valgrind looking for memory leaks with your
> particular animation as a shot in the dark. But, that's not something
> I'll get to for a while.

running with 480x360 and aa threshold .3 should do.


> Wondering too if the regular animation mechanisms can develop the memory
> bubbles seen with RTR. My guess is the frame rates with regular
> animation always too slow for it to happen - and as a light user of
> regular animation I've never noticed a (povms) memory bubble effect but,
> never gone looking for it, so who knows.

sorry, no ideas at all.  (it's as if the 'tmp_' dictionary is not updated in
time for next access)


regards, jr.

Post a reply to this message

Attachments:
Download 'frame_2800.txt' (4 KB)

On 3/17/22 11:19, jr wrote:
> Degenerate cylinder, base point = apex point.
> Fatal error in parser: Uncategorized error.
> Render failed

The three lines above come from a test during parsing while additional 
internal data for the cone/cylinder is being done using a function 
within cone.cpp. The tests is finding that the base and apex are <1e-10 
(a) apart - and throwing an error rather than issuing a parse error via 
message(b). The same code exists in POV-Ray proper v3.7 onward and povr 
(c).

(a) - The cone code hasn't been reworked as yet in povr to remove 
'EPSILON' use. The test value there should be ~4.4e-8 or povr's 
gkMinIsectDepthReturned. FWIW.

(b) - The particular test could be done completely inside the parser I 
think. Not sure why it's done in the cone/cylinder shape code.

(c) - There has long been a TODO note in the code suggesting that 
particular throw should be a 'possible error' instead - with execution 
continuing. I don't agree with the TODO note. Where base and apex are 
too close, it's an error in cone/cylinder specification.

---
The puzzle for me at the moment is I have no idea why those parsed base 
and apex vectors would be different between any versions of POV-Ray.

Best guess. It's due some indirect difference where I've moved to 
'double' from 'float' in povr and the previous 'snap' of the vector 
components to floats rounded length 'up' in a way not tripping the 
throw. In other words, values previously rounded such that the base to 
apex length is 'long enough'.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/17/22 11:19, jr wrote:
> > Degenerate cylinder, base point = apex point.
> > Fatal error in parser: Uncategorized error.
> > Render failed
>
> The three lines above come from a test during parsing while additional
> internal data for the cone/cylinder is being done using a function
> within cone.cpp. The tests is finding that the base and apex are <1e-10
> (a) apart - and throwing an error rather than issuing a parse error via
> message(b). The same code exists in POV-Ray proper v3.7 onward and povr
> (c).
>
> (a) - The cone code hasn't been reworked as yet in povr to remove
> 'EPSILON' use. The test value there should be ~4.4e-8 or povr's
> gkMinIsectDepthReturned. FWIW.
>
> (b) - The particular test could be done completely inside the parser I
> think. Not sure why it's done in the cone/cylinder shape code.
> ...
> The puzzle for me at the moment is I have no idea why those parsed base
> and apex vectors would be different between any versions of POV-Ray.

thank you v much.  the thing I don't understand is why, when every increment is
a whole unit, we'd get into a situation where (the value of) Epsilon would
matter.  and while the above reasoning does make sense, I can't shake the
feeling that, underneath, it's a dictionary "thing"/problem.


regards, jr.

Post a reply to this message

(correction)

"jr" <cre### [at] gmailcom> wrote:
> ...
> and while the above reasoning does make sense, I can't shake the
> feeling that, underneath, it's a dictionary "thing"/problem.

sorry, meant to write that the actual error is, I feel, misleading, and perhaps
is a dictionary/macro "thing".

<https://en.wikipedia.org/wiki/Allegory_of_the_cave>


regards, jr.

Post a reply to this message

On 3/18/22 03:32, jr wrote:
> (correction)
> 
> "jr" <cre### [at] gmailcom> wrote:
>> ...
>> and while the above reasoning does make sense, I can't shake the
>> feeling that, underneath, it's a dictionary "thing"/problem.
> 
> sorry, meant to write that the actual error is, I feel, misleading, and perhaps
> is a dictionary/macro "thing".
> 
> <https://en.wikipedia.org/wiki/Allegory_of_the_cave>
> 

Played a little with your animation this morning and see similar parse 
time fails. Continuing from the failing frame (ignoring whether this 
correct for the scene for now) always seems to work. So, it's not the 
particular frame calculations as you suggested.

The fails after re-starts from previous failing frames come faster and 
faster the larger the size of the usaf_items.csv file. This hints at a 
race condition where we are, perhaps, picking up base or apex twice as 
base and apex.

Debugging will take time I don't have at the moment. I'll capture the 
current work in a debug directory with the intent to come back to it later.

The good news is the fails are somewhat reproducible - though it's a bit 
of a pain to reach the 'fail more frequently' state.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Played a little with your animation this morning and see similar parse
> time fails.

glad it reproduces, and not result of compile-time choices/optimisation.

sorry for late-ish reply, re-ran the anim a number of times last night + this
morning.


> Continuing from the failing frame (ignoring whether this
> correct for the scene for now) always seems to work. So, it's not the
> particular frame calculations as you suggested.
>
> The fails after re-starts from previous failing frames come faster and
> faster the larger the size of the usaf_items.csv file. This hints at a
> race condition where we are, perhaps, picking up base or apex twice as
> base and apex.
> Debugging will take time I don't have at the moment. I'll capture the
> current work in a debug directory with the intent to come back to it later.

thanks.  adding some "data points" which, hopefully, will be of use then.

started with clean copy as posted, and in ini dialled down AA threshold (.3) and
commented out the 'all_file' line.  rendering then fails, with error, after
image 2799, repeatable[*] (take "similar" to mean you see different frame#?
anyway, expect it to stay the same).  I then switched verbose + logging off in
the scene, same error but after image 2876, also repeatable.  next tried with
verbose true but no logging, same error, this time after frame 2895.  then it
got .. tasty :-).  ran with verbose false and logging enabled, and got (out of
five runs) two successes and three segfaults (all past frame 3500, but different
#s).
  povray2[664477]: segfault at 25 ip 00000000004c733

[*] each test done twice or more.

I'd be interested to know whether your's too crashes.


> The good news is the fails are somewhat reproducible - though it's a bit
> of a pain to reach the 'fail more frequently' state.

not done it, but if state{curr} and items{point} agree, you should be able to
restart with '+kfi' etc.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ...
> thanks.  adding some "data points" which, hopefully, will be of use then.

another of-interest-perhaps point.  added a '#debug concat()' as first line of
the '__mkItems()' macro, outputting the macro arguments (of which index is not
o/wise used in the code).  now get a different error, at frame 2735: "Expected
'numeric expression', 'string identifier' found".  hypothesis - macro gets
wrong/corrupted set of args, the first of which (i_) happens to look like a
string?  anyway, intriguing (and annoying :-)).


regards, jr.

Post a reply to this message