|
From: Beorn J. <beo...@ya...> - 2005-05-15 06:05:54
|
Hello,
I am having trouble getting the leak-checker to translate locations
into symbolic form (probably all of valgrind, but I'm only using
mem-check/leak-check). A typical example is here:
==31429== 84 bytes in 1 blocks are possibly lost in loss record 488 of 713
==31429== at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132)
==31429== by 0x1DB63EEB: ???
==31429== by 0x1BD322F3: BasicClass::DFS(char const*, char const*, bool)
(BasicClass.cpp:71)
==31429== by 0x1DB4B800: ???
==31429== by 0x1BD32412: BasicClass::DFS(char const*, char const*, bool)
(BasicClass.cpp:92)
==31429== by 0x1D65E007: ???
==31429== by 0x1BD32412: BasicClass::DFS(char const*, char const*, bool)
(BasicClass.cpp:92)
==31429== by 0x1D0A70D8: ???
==31429== by 0x1BD32412: BasicClass::DFS(char const*, char const*, bool)
(BasicClass.cpp:92)
==31429== by 0x804AC1B: xxx_main(int, char**) (MainClass.h:66)
==31429== by 0x8049EE6: main (main.cpp:24)
(some names have been changed here).
The application depends on shared libraries, which in turn load more
shared objects via dlopen( ). All of the shared objects explicitly
loaded with dlopen( ) (and seemingly only these) fail to have their
addresses translated. The program also uses pthreads, mmap/munmap,
and shared memory (shmget( ), etc). I can look at /proc/$$/maps,
and the addresses map to the expected shared objects in all cases I
have checked. The run does not fork( ). It does catch lots
of signals.
----- Version information:
This is running valgrind 2.4.0 on Redhat AS 3.0; the application is mixed C/C++
using gcc/g++ 3.2.3; the system info is:
==31429== Contents of /proc/version:
==31429== Linux version 2.4.21-9.ELsmp (bhc...@st...)
(gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-26)) #1 SMP Thu Jan 8 17:08:56
EST 2004
uname -a is:
Linux XXX.com 2.4.21-9.ELsmp #1 SMP Thu Jan 8 17:08:56 EST 2004 i686
i686 i386 GNU/Linux)
Libc is:
-rwxr-xr-x 1 root root 1565724 Nov 7 2003
/lib/libc-2.3.2.so
lrwxr-xr-x 1 root root 13 May 6 08:29 /lib/libc.so.6
-> libc-2.3.2.so
----- What else I have tried / noticed:
I have tried a simplified test which does the same sort of
dlopen( ) operations, but there is no problem. The key bit of evidence
is that none of the 'dlopen()'-ed objects generate a "Reading syms from"
message; the last few "reading syms" messages are:
==31429== Reading syms from /lib/libgcc_s-3.2.3-20031114.so.1 (0x1BF96000)
==31429== Reading syms from /lib/tls/libc-2.3.2.so (0x1BFA2000)
==31429== Reading syms from /lib/tls/libpthread-0.60.so (0x1C0DB000)
==31429== Reading syms from /lib/libnss_files-2.3.2.so (0x1C1EF000)
Note 'ldd' on the base executable gives:
...
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f63000)
libc.so.6 => /lib/tls/libc.so.6 (0xb6e2b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb6e1a000)
Later on, I get:
==31429== discard syms at 0x1C1EF000-0x1C1FB000 in /lib/libnss_files-2.3.2.so
due to munmap()
I believe this occurs before the 'dlopen()'s start; I am unsure what
is going on with this particular shared object ('libnss_file').
I tried LD_PRELOADING this library, which got rid of the
"discard syms" message, but otherwise did not change the
original problem.
I have tried turning on some of the 'debug' variables, but
never having looked into the internals of valgrind, this
hasn't been very informative to me.
Thank you for any information/suggestings/hints that you can help
out with,
Beorn Johnson
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Discover Yahoo!
Use Yahoo! to plan a weekend, have fun online and more. Check it out!
http://discover.yahoo.com/
|
|
From: Tom H. <to...@co...> - 2005-05-15 08:33:32
|
In message <200...@we...>
Beorn Johnson <beo...@ya...> wrote:
> The application depends on shared libraries, which in turn load more
> shared objects via dlopen( ). All of the shared objects explicitly
> loaded with dlopen( ) (and seemingly only these) fail to have their
> addresses translated. The program also uses pthreads, mmap/munmap,
> and shared memory (shmget( ), etc). I can look at /proc/$$/maps,
> and the addresses map to the expected shared objects in all cases I
> have checked. The run does not fork( ). It does catch lots
> of signals.
You are presumably dlclosing those same files, which causes valgrind
to discard the name to address mapping so it can't then translate
stack traces involving those addresses.
The mappings are discarded because another library might later be
loaded at the same address and valgrind wouldn't know which set of
mappings to use.
The usual workaround is to prevent things being dlclosed when
running under valgrind.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-05-15 15:01:43
|
On Sun, 15 May 2005, Tom Hughes wrote: > You are presumably dlclosing those same files, which causes valgrind > to discard the name to address mapping so it can't then translate > stack traces involving those addresses. > > The mappings are discarded because another library might later be > loaded at the same address and valgrind wouldn't know which set of > mappings to use. > > The usual workaround is to prevent things being dlclosed when > running under valgrind. I've added a note about this to FAQ 4.4 (text)/5.4 (web). N |