|
From: Sree O. <so...@vm...> - 2005-07-29 21:54:58
|
Environment ~~~~~~~~~ $ uname -a Linux soggu-bld.vmware.com 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST = 2003 i686 i686 i386 GNU/Linux $ g++ -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs Configured with: ../configure --prefix=3D/usr --mandir=3D/usr/share/man --infodir=3D/usr/share/info --enable-shared --enable-threads=3Dposix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=3Di386-redhat-linux Thread model: posix gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) I am using Valgrind 2.4.0 on Linux and all my application source code = has been compiled with '-g' option. The application does load dynamc libraries but they are NOT 'dlclosed' = any time. I had to customise valgrind to make it understand some system calls and ioctls specific to our needs. I invoke valgrind with the addrcheck tool. Problem ~~~~~~ I found that for 2 consecutive runs of the same test sequence, valgrind reported the same number of bytes as 'still reachable' in the same = number of blocks. But each time the stack reported was entirely different. Also, the stack trace provided was not authentic, as it listed = functions that were not actually part of the function call. Additionally, the file names reported were not correct always. And in = some cases, it would provide the name of an unrelated library, though the corresponding source was compiled with '-g' option. Does valgrind report stack traces correctly when it involves function pointers and callbacks ? Below, I am enclosing the stack trace in each of the two cases. =3D=3D1786=3D=3D 3662581 bytes in 80390 blocks are still reachable in = loss record 555 of 555 =3D=3D1786=3D=3D at 0x34149534: malloc (vg_replace_malloc.c:130) =3D=3D1786=3D=3D by 0x3449D4D6: MemPoolStdHeap_Malloc (in = /usr/lib/libvmacore.so) # wrong library name=20 =3D=3D1786=3D=3D by 0x3448C52E: VmdbAllocStr (in = /usr/lib/libvmacore.so) # wrong library name =3D=3D1786=3D=3D by 0x34477EC4: Vmdb_SetCurrentPath (in = /usr/lib/libvmacore.so) =3D=3D1786=3D=3D by 0x3713364B: FoundryVMFinishAsyncChange = (foundryVM.c:3769) =3D=3D1786=3D=3D by 0x37133815: FoundryVMSetConfigVMDBCallback = (foundryVM.c:3858) =3D=3D1786=3D=3D by 0x371335EA: FoundryVMCbDemux (foundryVM.c:3735) # FoundryVMCbDemux is not invoked by Vmdb_ProcessCallbacks =3D=3D1786=3D=3D by 0x34478941: Vmdb_ProcessCallbacks (in = /usr/lib/libvmacore.so) =3D=3D1786=3D=3D by 0x34493DB9: (within /usr/lib/libvmacore.so) =3D=3D1786=3D=3D by 0x370CE34E: PollFireAndDequeue (poll.c:175) =3D=3D1786=3D=3D by 0x370CE7BF: PollExecuteDevice (poll.c:1410) =3D=3D1786=3D=3D by 0x370CD564: Poll_LoopTimeout (poll.c:427) =3D=3D2594=3D=3D 3662581 bytes in 80390 blocks are still reachable in = loss record 554 of 554 =3D=3D2594=3D=3D at 0x34149534: malloc (vg_replace_malloc.c:130) =3D=3D2594=3D=3D by 0x3449D4D6: MemPoolStdHeap_Malloc (in = /usr/lib/libvmacore.so) =3D=3D2594=3D=3D by 0x3448C52E: VmdbAllocStr (in = /usr/lib/libvmacore.so) =3D=3D2594=3D=3D by 0x34480A20: VmdbDbExec (in = /usr/lib/libvmacore.so) =3D=3D2594=3D=3D by 0x3448045D: VmdbDbCommitUpdatesLocally (in /usr/lib/libvmacore.so) =3D=3D2594=3D=3D by 0x3447FDD7: VmdbDbCommitUpdates (in = /usr/lib/libvmacore.so) =3D=3D2594=3D=3D by 0x3447C844: (within /usr/lib/libvmacore.so) # missing symbol name =3D=3D2594=3D=3D by 0x3447A3C4: (within /usr/lib/libvmacore.so) =3D=3D2594=3D=3D by 0x3447A350: Vmdb_EndTransaction (in = /usr/lib/libvmacore.so) =3D=3D2594=3D=3D by 0x344794FC: Vmdb_Unset (in = /usr/lib/libvmacore.so) =3D=3D2594=3D=3D by 0x37156097: FoundryCreateNewVm = (hostAgentStuff.c:207) =3D=3D2594=3D=3D by 0x371305C8: FoundryVM_CreateEx (foundryVM.c:593) Thanks in advance Sree |