[Valgrind-users] stack corruption update

[Roberto S. <ro...@mu...>]

I did some tests to isolate the problem

In fact, the first program against tested with valgrind had a problem of
uninitialized memory on the first run of the loop

That problem triggers another problem, this one inside valgrind it
seems; recalling the output of gdb:

==8200== Conditional jump or move depends on uninitialised value(s)
==8200==    at 0x804C031: main (lookt2.c:1243)
==8200==    by 0x40267DBD: __libc_start_main (in /lib/libc-2.3.2.so)
==8200==    by 0x8048D60: (within /pub/dev/lookthrough/new/lookt2)
==8200== 
==8200== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ----  y   
==8200== starting GDB with cmd: /usr/bin/gdb -nw /proc/8200/exe 8200
GNU gdb 5.3.90_2003-08-24-cvs-debian
...
vg_do_syscall3 (syscallno=4294966784, arg1=8228, arg2=0, arg3=0)
    at vg_mylibc.c:92
92      vg_mylibc.c: No such file or directory.
        in vg_mylibc.c
(gdb) bt
#0  vg_do_syscall3 (syscallno=4294966784, arg1=8228, arg2=0, arg3=0)
    at vg_mylibc.c:92
#1  0x40191b7d in vgPlain_system (
    cmd=0xbffff830 "/usr/bin/gdb -nw /proc/8200/exe 8200") 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  0xbffff938 in ?? ()
#5  0x0804c031 in main (argc=134534236, argv=0x0) at lookt2.c:1243


As you see, the frame n#5 has argc screwed up, and frame n#4 is
sospicious
Debugging from now on leads to unpredictable results

It turns out that any gdb session attached from valgrind is non-usable

The simple program attached here when debugged under valgrind has this
back trace:

#0  vg_do_syscall3 (syscallno=4294966784, arg1=2284, arg2=0, arg3=0)
    at vg_mylibc.c:92
#1  0x40191b7d in vgPlain_system (
    cmd=0xbffff7d0 "/usr/bin/gdb -nw /proc/2283/exe 2283") 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  0xbffff998 in ?? ()
#5  0x40021dca in strcpy (dst=0x0, src=0x0) at mac_replace_strmem.c:173
Previous frame identical to this frame (corrupt stack?)

That turns out to be bug 1406 already filled in at
http://sources.redhat.com/cgi-bin/gnatsweb.pl

This happens also on debian unstable with
gdb 5.3.90_2003-08-24-cvs-debian, valgrind 20030725-5 and libc 2.3.2-8

Along with the bug report, there's a suggestion from Mark Kettenis for a
fix in valgrind:
"There's something rather suspicious about frame #4; I doubt that
 you're really executing code on the stack.  It's defenitely more
 likely that GDB is unable to properly unwind frame #3.  I took a quick
 look at valgrind, and vgPlain_swizzle_esp_then_start_GDB() is
 hand-coded assembler that fiddles with the stack.  I'm not surprised
 that GDB chockes on this, and teaching GDB to properly unwind this
 particular frame is very difficult.  It's properly a better idea to
 ask the author of valgrind to add DWARF Call Frame Info (DWARF CFI) to
 this particular bit of code."

It would be a waste to have a tool like this not working on debian

Hope that helps
-- 
Roberto Sebastiano <ro...@mu...>