|
|
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
|
|