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: "scwuaptx at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 18 Mar 2015 20:55:20 +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
An-jie Yang <scwuaptx at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |scwuaptx at gmail dot com
--- Comment #3 from An-jie Yang <scwuaptx at gmail dot com> ---
(In reply to Pedro Alves from comment #1)
> 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.
I have the same problem and use a git master gdb on x86-32 ubuntu 14.04.
When I use "info frame" with a number witch not a number of frame in "bt", gdb
crashed.
(gdb) info frame 2
Stack frame at 0x0:
eip = 0x80484e1 in _start; saved eip = 0x80484e1
Outermost frame: outermost
caller of frame at 0xbffff500
Arglist at unknown address.
Locals at unknown address, Previous frame's sp in esp
(gdb) info frame 1
Stack frame at 0xbffff500:
eip = 0xb7e2aa83 in __libc_start_main; saved eip = 0x80484e1
called by frame at 0x0, caller of frame at 0xbffff490
Arglist at unknown address.
Locals at unknown address, Previous frame's sp is 0xbffff500
Saved registers:
ebx at 0xbffff4ec, ebp at 0xbffff4f8, esi at 0xbffff4f0, edi at 0xbffff4f4,
eip at 0xbffff4fc
(gdb) info frame 4
value.c:3821: internal-error: value_fetch_lazy: Assertion `frame != NULL'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
This is a bug, please report it. For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.
Aborted (core dumped)
I think the user who type the "info frame" should see that "The stack frame not
found" rather then crash.
So I patch parse_frame_specification such that it wouldn't create a new frame
when the frame number is not found.
diff --git a/gdb/stack.c b/gdb/stack.c
index 76a2360..5da2be8 100644
--- a/gdb/stack.c
+++ b/gdb/stack.c
@@ -1396,9 +1396,9 @@ parse_frame_specification_1 (const char *frame_exp, const
/* We couldn't identify the frame as an existing frame, but
perhaps we can create one with a single argument. */
if (numargs == 1)
- return create_new_frame (addrs[0], 0);
+ error (_("The stack frame not found"));
else if (numargs == 2)
- return create_new_frame (addrs[0], addrs[1]);
+ error (_("The stack frame not found"));
else
error (_("Too many args in frame specification"));
}
After I patch it, I tried to type "info frame" with wrong number and correct
number,it work normally and does not crash.
But I don't know would there have any effects ?
--
You are receiving this mail because:
You are on the CC list for the bug.