This is the mail archive of the
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: Mon, 18 Nov 2013 11:23:02 -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>
>> + if (VALUE_LVAL (new_val) == lval_register
>> + && value_lazy (new_val)
>> + && frame_id_eq (VALUE_FRAME_ID (new_val), last_frame_id))
Pedro> I think this should also check the regnum:
Barf. I have a memory of actually writing that. False memory I guess.
>> #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> Doesn't this all then mean that we somehow ended up with two identical
Pedro> frames with the same id on the frame chain (#4 and #5) ?
Pedro> That seems very wrong to me.
Pedro> It seems to be a better fix would be to make
Pedro> get_prev_frame_1/get_prev_frame_raw discard frame #5 before it
Pedro> was ever linked in. Either that, or, if we really need to keep
Pedro> #5 linked in, we should find a way for frame_id_eq (#4, #5) to
Pedro> return false.
I will look into it, but my recollection is that last time we got into
this area, it was somehow undesirable to undo whatever changes were done
by existing frame sniffers.