[Bug gdb/18074] crash using "info frame"

["scwuaptx at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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.