This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/18074] crash using "info frame"
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 02 Mar 2015 22:58:39 +0000
- Subject: [Bug gdb/18074] crash using "info frame"
- Auto-submitted: auto-generated
- References: <bug-18074-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18074
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com
--- Comment #1 from Pedro Alves <palves at redhat dot com> ---
Man, we _still_ haven't fixed this... :-/
"frame ADDR" / "info frame ADDR" are very broken at several levels, IMO. Even
though in your case, you explicitly wanted a frame at an address, the fact that
the user can typo a frame number and GDB ends up creating a new frame on the
spot is quite misleading. It should be an explicit switch for "create frame if
you can't find it in the frame frame", IMO:
https://sourceware.org/ml/gdb/2014-11/msg00028.html
In addition, I think I'd expect "bt" after "frame ADDR" to attempt to
backtracing starting at that created frame.
The crash in this case is a different bogosity: parse_frame_specification at
the tail end creates the new frame, but "current_frame" is not set to point at
it. So, here:
3808 while (VALUE_LVAL (new_val) == lval_register && value_lazy
(new_val))
3809 {
3810 struct frame_id frame_id = VALUE_FRAME_ID (new_val);
3811
3812 frame = frame_find_by_id (frame_id);
3813 regnum = VALUE_REGNUM (new_val);
This looks up that frame that was created for ADDR in the frame chain, starting
at current_frame, and of course that never finds that hacked up frame...
Maybe parse_frame_specification should override current_frame. But it isn't
that simple: we also need to handle the cases where gdb switches thread/frame
behind the user's back temporarily, and then restores them
(do_restore_current_thread_cleanup / restore_selected_frame use), in which case
we'd need to restore that cooked up frame.
--
You are receiving this mail because:
You are on the CC list for the bug.