This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

backtrace/1406: gdb 5.3/6.0 broken with valgrind --gdb-attach=yes (gdb refuses to display the stack frame)


>Number:         1406
>Category:       backtrace
>Synopsis:       gdb 5.3/6.0 broken with valgrind --gdb-attach=yes (gdb refuses to display the stack frame)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 05 11:18:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     pommier@gmm.insa-tlse.fr
>Release:        6.0
>Organization:
>Environment:
(debian sid, x86)
gdb 5.3.90_2003-08-24-cvs-debian,  gdb-6.0
valgrind-20030725, valgrind-1.0.4
gcc-2.95, gcc-3.2, gcc-3.3
glibc 2.3.2
>Description:
gdb 5.3 or gdb 6.0 won't display the stack frame [ "Previous frame identical to this frame (corrupt stack?)" ] when is has been invoked by valgrind --gdb-attach=yes. I did not have this problem with gdb 5.2, and it does not seem to be related to a particular valgrind version or gcc version.
>How-To-Repeat:
> cat > t.c
#include <string.h>
int coin() {
  char *s = strdup("plop");
  int i = s[5];
  return i;
}
void coincoin() { coin(); }
int main() {
  coincoin();
  return 0;
}
> gcc -g t.c && valgrind --gdb-attach=yes a.out
==3160== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==3160== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==3160== Using valgrind-20030725, a program supervision framework for
x86-linux.
==3160== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==3160== Estimated CPU clock rate is 2034 MHz
==3160== For more details, rerun with: -v
==3160==
==3160== Invalid read of size 1
==3160==    at 0x8048401: coin (k.c:5)
==3160==    by 0x804841E: coincoin (k.c:9)
==3160==    by 0x804842E: main (k.c:12)
==3160==    by 0x40264DBD: __libc_start_main (in /lib/libc-2.3.2.so)
==3160==    Address 0x410B7029 is 0 bytes after a block of size 5
alloc'd
==3160==    at 0x4002A6F1: malloc (vg_replace_malloc.c:153)
==3160==    by 0x402C4F6F: __strdup (in /lib/libc-2.3.2.so)
==3160==    by 0x80483F2: coin (k.c:4)
==3160==    by 0x804841E: coincoin (k.c:9)
==3160==
==3160== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y
==3160== starting GDB with cmd: /usr/bin/gdb -nw /proc/3160/exe 3160
GNU gdb 5.3.90_2003-08-24-cvs-debian
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-linux"...w
Attaching to program: /proc/3160/exe, process 3160
Reading symbols from /usr/lib/valgrind/vgskin_memcheck.so...done.
Loaded symbols for /usr/lib/valgrind/vgskin_memcheck.so
Reading symbols from /usr/lib/valgrind/valgrind.so...done.
Loaded symbols for /usr/lib/valgrind/valgrind.so
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
vg_do_syscall3 (syscallno=4294966784, arg1=3161, arg2=0, arg3=0)
    at vg_mylibc.c:92
92      vg_mylibc.c: No such file or directory.
        in vg_mylibc.c
(gdb) where
#0  vg_do_syscall3 (syscallno=4294966784, arg1=3161, arg2=0, arg3=0)
    at vg_mylibc.c:92
#1  0x40191b7d in vgPlain_system (cmd=0xbffff040 "/usr/bin/gdb -nw /proc/3160/exe
    3160") at vg_mylibc.c:1277
#2  0x4018d727 in
    vgPlain_start_GDB_whilst_on_client_stack () at vg_main.c:1821
#3  0x40194e48 in vgPlain_swizzle_esp_then_start_GDB()
    from /usr/lib/valgrind/valgrind.so
#4  0xbffff0d8 in ?? ()
#5  0x08048401 in coin () at k.c:5
Previous frame identical to this frame (corrupt stack?)
(gdb)
>Fix:
removing the duplicate frame check in gdb/frame.c fixes the problem, although the stack is now displayed as
#5  0x08048401 in coin () at k.c:5
#6  0x08048401 in coin () at k.c:5
#7  0x0804841f in coincoin () at k.c:9
#8  0x0804842f in main () at k.c:12
with frame #5 being invalid, the others are correct.


--- frame.c     2003-10-05 12:46:26.000000000 +0200
+++ frame.c~    2003-09-08 20:58:13.000000000 +0200
@@ -1979,11 +1979,11 @@
   /* Check that this and the next frame are not identical.  If they
      are, there is most likely a stack cycle.  As with the inner-than
      test above, avoid comparing the inner-most and sentinel frames.  */
-  /*  if (this_frame->level > 0
+  if (this_frame->level > 0
       && frame_id_eq (get_frame_id (this_frame),
                      get_frame_id (this_frame->next)))
     error ("Previous frame identical to this frame (corrupt stack?)");
-  */
+
   /* Allocate the new frame but do not wire it in to the frame chain.
      Some (bad) code in INIT_FRAME_EXTRA_INFO tries to look along
      frame->next to pull some fancy tricks (of course such code is, by
>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]