|
From: <go...@co...> - 2006-03-31 16:47:59
|
I am relatively new to this so forgive me if this is a stupid question. I am trying to memcheck on RHEL4/Opteron with --db-attach. Whenever I encounter a valgrind error and try to gdb, I get either "no stack" or something entirely different than the valgrind call chain (I believe the valgrind chain to be correct). If I run the application under gdb, the backtrace appears to be correct, so it appears to be something in the way valgrind is passing context to the debugger. Below is an example. How would I go about figuring out where the disconnect is ? TIA bash-3.00$ valgrind --num-callers=50 --tool=memcheck --db-attach=yes ./vts ==16759== Memcheck, a memory error detector. ==16759== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==16759== Using LibVEX rev 1575, a library for dynamic binary translation. ==16759== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==16759== Using valgrind-3.1.1, a dynamic binary instrumentation framework. ==16759== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==16759== For more details, rerun with: -v ==16759== ==16759== Source and destination overlap in memcpy(0x4B9BBF8, 0x4B9BBF8, 8) ==16759== at 0x4906AE4: memcpy (mac_replace_strmem.c:394) ==16759== by 0x32C7532ABD: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C753324D: _XtGetResources (in /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751C16B: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751CDC5: _XtAppCreateShell (in /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751CEDD: XtAppCreateShell (in /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C316719D: (within /usr/X11R6/lib64/libXm.so.3.0.2) ==16759== by 0x32C3167293: XmGetXmDisplay (in /usr/X11R6/lib64/libXm.so.3.0.2) ==16759== by 0x32C316A2A7: (within /usr/X11R6/lib64/libXm.so.3.0.2) ==16759== by 0x32C315B75E: (within /usr/X11R6/lib64/libXm.so.3.0.2) ==16759== by 0x32C751BC2C: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751BBFC: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751BBFC: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751BBFC: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751BBFC: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751BBFC: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751BBFC: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751BBFC: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751BBFC: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751BBFC: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751C1F6: (within /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C751CDC5: _XtAppCreateShell (in /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C754B868: XtVaAppCreateShell (in /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C754C07B: _XtVaOpenApplication (in /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x32C754C298: XtVaAppInitialize (in /usr/X11R6/lib64/libXt.so.6.0) ==16759== by 0x44E460: main (vts.c:1241) ==16759== ==16759== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y starting debugger ==16759== starting debugger with cmd: /usr/bin/gdb -nw /proc/16761/fd/1014 16761 GNU gdb Red Hat Linux (6.3.0.0-1.63rh) Copyright 2004 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 "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1". Attaching to program: /proc/16761/fd/1014, process 16761 0x0000000004906ae4 in ?? () (gdb) bt #0 0x0000000004906ae4 in ?? () #1 0x00000032c765dd80 in ?? () #2 0x00000032c7532abe in ?? () #3 0x0000000200000000 in ?? () #4 0x00000032c38101ce in ?? () #5 0x0000000000000000 in ?? () (gdb) |