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

On 3/19/22 09:41, jr wrote:
> 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.

Looking at this issue again after a year! (Sorry)

I can now see the exact re-producible fails you'd mentioned. I changed 
the cylinder source code so it simply writes the duplicate apex base 
vectors rather than issue a throw(a). Starting always from a saved case 
which reached frame 3000. I run repeatedly and it is always the same 
three fails!

I, like you, have had other fail signatures, but it looks like if we 
start with certain fixed conditions the fail points are indeed the same.
This perhaps enough information for me to insert a break point.

I've tried a few other things shooting in the dark and like you get as 
often as not 'other' odd results.

---

At the moment I am trying to get your seg fault signature above using a 
debug compile having symbols - where the core file generated should be 
useful.

You didn't get this fail every time, and so far I've not gotten a 
segfault. I'm just running it and running it again for a while with 
verbose false and logging enabled. We'll see.

Bill P.

Post a reply to this message

On 3/24/23 11:39, William F Pokorny wrote:
> At the moment I am trying to get your seg fault signature above using a 
> debug compile having symbols - where the core file generated should be 
> useful.
> 
> You didn't get this fail every time, and so far I've not gotten a 
> segfault. I'm just running it and running it again for a while with 
> verbose false and logging enabled. We'll see.

No segfaults of the differing type you saw.

I did get two different Parse Error signatures early. One for an array 
subscript out of range and another via the include of parse_fore.tmp 
attempting to access an uninitialized array element. Neither made sense 
to me.

Then the blasted povr code proceeded to run cleanly both partial runs 
and full ones for 6 passes.

I went back to the original failing set up starting at frame 3000 with 
both verbose and log frames on - which had been failing at the same 
'spots' for me - and at least the most recent pass decided other spots / 
cylinders should now fail.

Only thing that's clear is what was clear before - we have no problems 
until the frame counts are 2500, 3000 or more.

Anyhow. Answering the question you asked a year ago. I don't see the 
segfaults you saw with verbose off and logging on. Mostly things worked 
in this configuration...

Future posts on this povr only problem, I'll put in a new thread 
somewhere. Probably user.patches. This thread got really long and became 
'twelve ways' unrelated to the original topic!

Bill P.

Post a reply to this message