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