|
From: Mehmet T. <mt...@ad...> - 2005-08-17 15:32:08
|
Hi all,
I'm using Suse 9.0 with kernel 2.4.21 built for x86_64 (AMD x86_64).
Valgrind reports possible memory leak:
==1878== LEAK SUMMARY:
==1878== definitely lost: 0 bytes in 0 blocks.
==1878== possibly lost: 11928 bytes in 14 blocks.
==1878== still reachable: 66032 bytes in 3 blocks.
==1878== suppressed: 0 bytes in 0 blocks.
The detailed leak message claims that the leak happened within "pthread_create"
and "pthread_join" functions of the pthread library. Can anyone tell me how
seriously should I take this leak message?
The code snippet and detailed leak message is below...
Thanks,
Mehmet
========================================
class graphManager {
public:
pthread_t m_th;
pthread_attr_t m_thAttr;
int addNode(....);
}
void *threadFunc(void *ptr);
int graphManager::addNode(....) {
pthread_attr_init(&m_thAttr);
return pthread_create(&m_th, &m_thAttr, threadFunc, (void *) this);
}
=========================================
==1877== Syscall param clone(child_tidptr) contains uninitialised byte(s)
==1877== at 0x12087E64: clone (in /lib64/libc.so.6)
==1877== by 0x11E28948: __pthread_initialize_manager
(in /lib64/libpthread.so.0)
==1877== by 0x11E28BCA: pthread_create@@GLIBC_2.2.5
(in /lib64/libpthread.so.0)
==1877== by 0x4051C1: graphManager::addNode(mtsdNode*, AdeNodeConfig*)
(graphMan.cpp:84)
==1877== by 0x401FEC: main (graphdata.cpp:61)
==1877==
==1877== Syscall param write(buf) points to uninitialised byte(s)
==1877== at 0x11E2BCEF: write (in /lib64/libpthread.so.0)
==1877== by 0x11E289A2: __pthread_initialize_manager
(in /lib64/libpthread.so.0)
==1877== by 0x11E28BCA: pthread_create@@GLIBC_2.2.5
(in /lib64/libpthread.so.0)
==1877== by 0x4051C1: graphManager::addNode(mtsdNode*, AdeNodeConfig*)
(graphMan.cpp:84)
==1877== by 0x401FEC: main (graphdata.cpp:61)
==1877== Address 0x349FDEC0 is on thread 1's stack
==1877==
==1877== Syscall param write(buf) points to uninitialised byte(s)
==1877== at 0x11E2BCEF: write (in /lib64/libpthread.so.0)
==1877== by 0x11E28B7E: pthread_create@@GLIBC_2.2.5
(in /lib64/libpthread.so.0)
==1877== by 0x4051C1: graphManager::addNode(mtsdNode*, AdeNodeConfig*)
(graphMan.cpp:84)
==1877== by 0x401FEC: main (graphdata.cpp:61)
==1877== Address 0x349FDFAC is on thread 1's stack
==1877==
==1877== Syscall param write(buf) points to uninitialised byte(s)
==1877== at 0x11E2BCEF: write (in /lib64/libpthread.so.0)
==1877== by 0x11E28B7E: pthread_create@@GLIBC_2.2.5
(in /lib64/libpthread.so.0)
==1877== by 0x4051C1: graphManager::addNode(mtsdNode*, AdeNodeConfig*)
(graphMan.cpp:84)
==1877== by 0x402021: main (graphdata.cpp:64)
==1877== Address 0x349FDFAC is on thread 1's stack
==1877==
==1877== Syscall param write(buf) points to uninitialised byte(s)
==1877== at 0x11E2BCEF: write (in /lib64/libpthread.so.0)
==1877== by 0x11E28B7E: pthread_create@@GLIBC_2.2.5
(in /lib64/libpthread.so.0)
==1877== by 0x4051C1: graphManager::addNode(mtsdNode*, AdeNodeConfig*)
(graphMan.cpp:84)
==1877== by 0x402056: main (graphdata.cpp:67)
==1877== Address 0x349FDFAC is on thread 1's stack
==1877==
==1877== Syscall param write(buf) points to uninitialised byte(s)
==1877== at 0x11E2BCEF: write (in /lib64/libpthread.so.0)
==1877== by 0x11E28B7E: pthread_create@@GLIBC_2.2.5
(in /lib64/libpthread.so.0)
==1877== by 0x4051C1: graphManager::addNode(mtsdNode*, AdeNodeConfig*)
(graphMan.cpp:84)
==1877== by 0x40208B: main (graphdata.cpp:67)
==1877== Address 0x349FDFAC is on thread 1's stack
==1877==
==1877== Syscall param write(buf) points to uninitialised byte(s)
==1877== at 0x11E2BCEF: write (in /lib64/libpthread.so.0)
==1877== by 0x11E28B7E: pthread_create@@GLIBC_2.2.5
(in /lib64/libpthread.so.0)
==1877== by 0x4051C1: graphManager::addNode(mtsdNode*, AdeNodeConfig*)
(graphMan.cpp:84)
==1877== by 0x4020C0: main (graphdata.cpp:67)
==1877== Address 0x349FDFAC is on thread 1's stack
--1877-- REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x7002896F (???)
|
|
From: Tom H. <to...@co...> - 2005-08-17 15:37:03
|
In message <loo...@po...>
Mehmet Tek <mt...@ad...> wrote:
> I'm using Suse 9.0 with kernel 2.4.21 built for x86_64 (AMD x86_64).
> Valgrind reports possible memory leak:
>
> ==1878== LEAK SUMMARY:
> ==1878== definitely lost: 0 bytes in 0 blocks.
> ==1878== possibly lost: 11928 bytes in 14 blocks.
> ==1878== still reachable: 66032 bytes in 3 blocks.
> ==1878== suppressed: 0 bytes in 0 blocks.
>
> The detailed leak message claims that the leak happened within "pthread_create"
> and "pthread_join" functions of the pthread library. Can anyone tell me how
> seriously should I take this leak message?
>
> The code snippet and detailed leak message is below...
None of the messages you posted is a leak message. They are all
warnings about uninitialised system call arguments. You need to
use --leak-check=yes if you want to get leak details.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Mehmet T. <mt...@ad...> - 2005-08-17 17:37:48
|
Tom Hughes <tom <at> compton.nu> writes: > > In message <loom.20050817T163604-72 <at> post.gmane.org> > Mehmet Tek <mtek <at> ade.com> wrote: > > > I'm using Suse 9.0 with kernel 2.4.21 built for x86_64 (AMD x86_64). > > Valgrind reports possible memory leak: > > > > ==1878== LEAK SUMMARY: > > ==1878== definitely lost: 0 bytes in 0 blocks. > > ==1878== possibly lost: 11928 bytes in 14 blocks. > > ==1878== still reachable: 66032 bytes in 3 blocks. > > ==1878== suppressed: 0 bytes in 0 blocks. > > > > The detailed leak message claims that the leak happened within "pthread_create" > > and "pthread_join" functions of the pthread library. Can anyone tell me how > > seriously should I take this leak message? > > > > The code snippet and detailed leak message is below... > > None of the messages you posted is a leak message. They are all > warnings about uninitialised system call arguments. You need to > use --leak-check=yes if you want to get leak details. > > Tom > Thanks for the advice. With leak checking on, the results are below. My call to pthread_create has nothing tricky about it. Do you think there is a leak in the pthread library? Thanks, Mehmet ==2433== 272 bytes in 2 blocks are possibly lost in loss record 1 of 4 ==2433== at 0x11B1D427: calloc (vg_replace_malloc.c:279) ==2433== by 0x1190DD59: allocate_dtv (in /lib64/ld-2.3.2.so) ==2433== by 0x1190DE12: _dl_allocate_tls_storage (in /lib64/ld-2.3.2.so) ==2433== by 0x1190E014: _dl_allocate_tls (in /lib64/ld-2.3.2.so) ==2433== by 0x11E282CD: __pthread_initialize_minimal (in /lib64/libpthread.so.0) ==2433== by 0x11E25358: (within /lib64/libpthread.so.0) ==2433== ==2433== ==2433== 3136 bytes in 2 blocks are possibly lost in loss record 3 of 4 ==2433== at 0x11B1D5DD: memalign (vg_replace_malloc.c:332) ==2433== by 0x1190DDE8: _dl_allocate_tls_storage (in /lib64/ld-2.3.2.so) ==2433== by 0x1190E014: _dl_allocate_tls (in /lib64/ld-2.3.2.so) ==2433== by 0x11E282CD: __pthread_initialize_minimal (in /lib64/libpthread.so.0) ==2433== by 0x11E25358: (within /lib64/libpthread.so.0) ==2433== ==2433== ==2433== 8160 bytes in 1 blocks are definitely lost in loss record 4 of 4 ==2433== at 0x11B1C106: malloc (vg_replace_malloc.c:149) ==2433== by 0x11E28817: __pthread_initialize_manager (in /lib64/libpthread.so.0) ==2433== by 0x11E28BCA: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread.so.0) ==2433== by 0x404E2B: graphManager::addNode(mtsdNode*, AdeNodeConfig*) (in /root/Mehmet/newArch/test/graphdata) ==2433== by 0x401EB1: main (in /root/Mehmet/newArch/test/graphdata) ==2433== ==2433== LEAK SUMMARY: ==2433== definitely lost: 8160 bytes in 1 blocks. ==2433== possibly lost: 3408 bytes in 4 blocks. ==2433== still reachable: 1040 bytes in 1 blocks. ==2433== suppressed: 0 bytes in 0 blocks. ==2433== Reachable blocks (those to which a pointer was found) are not shown. ==2433== To see them, rerun with: --show-reachable=yes --2433-- memcheck: sanity checks: 179 cheap, 8 expensive --2433-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --2433-- memcheck: auxmaps: 0 searches, 0 comparisons --2433-- memcheck: secondaries: 28 issued (1792k, 1M) --2433-- memcheck: secondaries: 180 accessible and distinguished (11520k, 11M) --2433-- tt/tc: 8040 tt lookups requiring 8441 probes --2433-- tt/tc: 8040 fast-cache updates, 5 flushes --2433-- translate: new 3865 (84727 -> 1599770; ratio 188:10) [0 scs] --2433-- translate: dumped 0 (0 -> ??) --2433-- translate: discarded 11 (193 -> ??) --2433-- scheduler: 7085823 jumps (bb entries). --2433-- scheduler: 179/83938 major/minor sched events. --2433-- sanity: 180 cheap, 8 expensive checks. --2433-- exectx: 4999 lists, 54 contexts (avg 0 per list) --2433-- exectx: 88 searches, 66 full compares (750 per 1000) --2433-- exectx: 4 cmp2, 61 cmp4, 0 cmpAll |