|
From: Charles-Henri d'A. <cda...@gm...> - 2009-01-27 09:23:35
|
Hello all !
I have a still reachable issue with the backtrace function from
libexecinfo from GNU libc
on SuSE Linux Entreprise 9.3 with gcc 3.4.2 , glibc-2.3.3 and valgrind-3.3.0.
See below a very simple and reproducible programm.
Do any of you know if it is an issue from my code, glibc or valgrind, please ?
Thank you very much for your help !
Cheers,
Chicha.
// PROGRAM START
#include <cstdlib>
#include <execinfo.h>
#define MAX_BACKTRACE_SIZE 100
int main()
{
void * stackAddresses[100] = {0};
size_t stackSize = backtrace(stackAddresses, 100);
return 0;
}
// PROGRAM END
// VALGRIND REPORT START
==7635== 56 bytes in 1 blocks are still reachable in loss record 1 of 1
==7635== at 0x4A1A0A7: malloc (vg_replace_malloc.c:207)
==7635== by 0x400A605: _dl_map_object_deps (in /lib64/ld-2.3.3.so)
==7635== by 0x505D776: dl_open_worker (in /lib64/tls/libc.so.6)
==7635== by 0x400B2DD: _dl_catch_error (in /lib64/ld-2.3.3.so)
==7635== by 0x505D15F: _dl_open (in /lib64/tls/libc.so.6)
==7635== by 0x505EF17: do_dlopen (in /lib64/tls/libc.so.6)
==7635== by 0x400B2DD: _dl_catch_error (in /lib64/ld-2.3.3.so)
==7635== by 0x505EDEA: dlerror_run (in /lib64/tls/libc.so.6)
==7635== by 0x505EED7: __libc_dlopen_mode (in /lib64/tls/libc.so.6)
==7635== by 0x503E409: init (in /lib64/tls/libc.so.6)
==7635== by 0x503E4F6: backtrace (in /lib64/tls/libc.so.6)
==7635== by 0x400679: main (in
/remote/users2/cdadhema/dev/tests/string_leaks/test3)
==7635==
==7635== LEAK SUMMARY:
==7635== definitely lost: 0 bytes in 0 blocks.
==7635== possibly lost: 0 bytes in 0 blocks.
==7635== still reachable: 56 bytes in 1 blocks.
==7635== suppressed: 0 bytes in 0 blocks.
// VALGRIND REPORT END
|
> ==7635== 56 bytes in 1 blocks are still reachable in loss record 1 of 1 > ==7635== at 0x4A1A0A7: malloc (vg_replace_malloc.c:207) > ==7635== by 0x400A605: _dl_map_object_deps (in /lib64/ld-2.3.3.so) ... > ==7635== by 0x505EDEA: dlerror_run (in /lib64/tls/libc.so.6) > ==7635== by 0x505EED7: __libc_dlopen_mode (in /lib64/tls/libc.so.6) > ==7635== by 0x503E409: init (in /lib64/tls/libc.so.6) > ==7635== by 0x503E4F6: backtrace (in /lib64/tls/libc.so.6) It's an incomplete interface deep inside the runtime dynamic linker of glibc. Neither you nor the implementers of memcheck can do anything about it. -- |
|
From: Charles-Henri d'A. <cda...@gm...> - 2009-01-27 14:51:26
|
Thank you very much John for your answer ! I also though it came from glibc but I just wanted to make sure I was not missing a stupid mistake from myself ... Thanks a lot again . Cheers, CH 2009/1/27 John Reiser <jr...@bi...>: >> ==7635== 56 bytes in 1 blocks are still reachable in loss record 1 of 1 >> ==7635== at 0x4A1A0A7: malloc (vg_replace_malloc.c:207) >> ==7635== by 0x400A605: _dl_map_object_deps (in /lib64/ld-2.3.3.so) > ... >> ==7635== by 0x505EDEA: dlerror_run (in /lib64/tls/libc.so.6) >> ==7635== by 0x505EED7: __libc_dlopen_mode (in /lib64/tls/libc.so.6) >> ==7635== by 0x503E409: init (in /lib64/tls/libc.so.6) >> ==7635== by 0x503E4F6: backtrace (in /lib64/tls/libc.so.6) > > It's an incomplete interface deep inside the runtime dynamic linker of glibc. > Neither you nor the implementers of memcheck can do anything about it. > > -- > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |