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