RE: [reSIProcate] Potential memory leak in RRCache
I am using valgrind with these options.
valgrind -v --tool=memcheck --trace-children=yes --leak-check=full <application
name and parameters>
Mike
________________________________________
From: Noiile [mailto:noiile@xxxxxxxxxxx]
Sent: Monday, January 23, 2006 2:29 AM
To: Michael Baj; resiprocate-devel
Subject: Re: [reSIProcate] Potential memory leak in RRCache
Michael Baj, Hello
what tool do you use ?
Noiile, noiile@xxxxxxxxxxx
2006-1-23
----- Receiving the following content -----
From: Michael Baj
Receiver: resiprocate-devel
Time: 2006-01-23, 02:51:01
Subject: [reSIProcate] Potential memory leak in RRCache
I am running some perfomance tests with a simple proxy and registrar using
resiprocate. I noticed that while running my applications through valgrind,
memory is not being freed from RRCache. I recognize that there exists a static
std::auto_ptr of the RRCache instance which should call cleanup() when the last
reference goes away, but this never seems to be the case. Also, the amount of
memory not being freed, is directly proportional to the number of transactions
being processed (e.g. the more transations, the greater the amount of memory
not being freed). Is there something that I should be doing at the end of my
main routine to ensure that the RRCache gets cleaned up properly or is this
really a problem?
Thanks,
Mike
==8844== 155816 bytes in 32 blocks are still reachable in loss record 11 of 11
==8844== at 0x1B9036BE: operator new(unsigned) (vg_replace_malloc.c:132)
==8844== by 0x1C0091C0: std::__default_alloc_template<true,
0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.3)
==8844== by 0x1C0090CC: std::__default_alloc_template<true,
0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.3)
==8844== by 0x1C008C3B: std::__default_alloc_template<true,
0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.3)
==8844== by 0x1BE0CEA7:
std::__simple_alloc<std::_Rb_tree_node<resip::RRList*>,
std::__default_alloc_template<true, 0> >::allocate(unsigned) (stl_alloc.h:238)
==8844== by 0x1BE0C8F9: std::_Rb_tree_alloc_base<resip::RRList*,
std::allocator<resip::RRList*>, true>::_M_get_node() (stl_tree.h:564)
==8844== by 0x1BE0BF44: std::_Rb_tree_base<resip::RRList*,
std::allocator<resip::RRList*> >::_Rb_tree_base(std::allocator<resip::RRList*>
const&) (stl_tree.h:579)
==8844== by 0x1BE0B4CE: std::_Rb_tree<resip::RRList*, resip::RRList*,
std::_Identity<resip::RRList*>, resip::RRCache::CompareT,
std::allocator<resip::RRList*> >::_Rb_tree(resip::RRCache::CompareT const&,
std::allocator<resip::RRList*> const&) (stl_tree.h:730)
==8844== by 0x1BE0AC9E: std::set<resip::RRList*, resip::RRCache::CompareT,
std::allocator<resip::RRList*> >::set() (stl_set.h:116)
==8844== by 0x1BE09BC2: resip::RRCache::RRCache() (RRCache.cxx:57)
==8844== by 0x1BE0AB71: __static_initialization_and_destruction_0(int, int)
(RRCache.cxx:50)
==8844== by 0x1BE0AC27: _GLOBAL__I__ZN5resip7RRCache9mInstanceE
(stl_map.h:110)