Re: [PATCH 1/2] avoid infinite loop with bad debuginfo

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Tom> I can probably find another test case

Pedro> Yes, probably by manually creating a corrupted stack.

Actually I was thinking of something simpler...

Pedro> I think this is an old latent problem.  We shouldn't ever have
Pedro> two frames with the same id in the frame chain, lots of things
Pedro> break otherwise.  But somehow, we managed to get this far
Pedro> in this particular case.

Ok, thanks for this analysis.

Pedro> If we can indeed trigger this with a real corruption test
Pedro> case, I believe the reason is that the recent-ish addition
Pedro> of the frame stash exposes the latent bug:

Nice insight.

To me this is another internal constraint of the unwinder design that is
being violated "somewhere".  It seems like we can't really write an
ordinary test case for it -- since it is a "shouldn't happen" scenario.

Pedro> I still think that such a loop should be broken by never
Pedro> having two frames with the same id in the frame chain in the
Pedro> first place.  This potential infinite loop in value_fetch_lazy
Pedro> is really an internal error, IMO.

It seems to me that the loop in question could perhaps be reached from
some path outside the unwinder.  If so, bad DWARF would be able to cause
an internal error -- clearly incorrect.  I suppose one idea is that the
DWARF code should do the checking itself, though.

Tom