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 13:24:26 -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> <87siusl10r dot fsf at fleche dot redhat dot com> <528BB700 dot 4000802 at redhat dot com>
Pedro> I don't think so, because get_prev_frame_1 would not link in
Pedro> the dup frame. The loop in question would never see it.
Pedro> Hmm, I think one of us is missing something.
Haha, yeah, that usually means me :-)
No worries. I think I understand this bit now.
Pedro> So the bad loop can only ever happen (outside the unwinder code)
Pedro> if we ever let outselves get in the dup frame_id situation:
>> #4 0x0000007fb7f0956c in clone () from /lib64/libc.so.6
>> #5 0x0000007fb7f0956c in clone () from /lib64/libc.so.6
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Pedro> At least, I'm not seeing any other way.
Yes, I see now.
Really not looking forward to writing the test.
Tom