This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] avoid infinite loop with bad debuginfo
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 19 Nov 2013 11:06:12 -0700
- Subject: Re: [PATCH 1/2] avoid infinite loop with bad debuginfo
- Authentication-results: sourceware.org; auth=none
- References: <1384375873-32160-1-git-send-email-tromey at redhat dot com> <1384375873-32160-2-git-send-email-tromey at redhat dot com> <52850730 dot 1060109 at redhat dot com> <87d2lxpo1l dot fsf at fleche dot redhat dot com> <528B7F15 dot 7040605 at redhat dot com> <87vbzomm78 dot fsf at fleche dot redhat dot com> <528B8FF6 dot 7000406 at redhat dot 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