|
From: Roberto S. <ro...@mu...> - 2003-10-08 17:34:22
|
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...>
|