[Insight-users] memory leak check in ITK?
Feng Ma
mafeng at hotmail . com
Fri, 26 Sep 2003 14:28:34 -0400
Hi, Luis:
Thanks for the help. I did the modification as instructed. It does fix
some meory leakage: 48 bytes definitely lost and 72 possibly lost. But I saw
some new memory leak and appear more subtle to me.
==9873== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==9873== Using valgrind-20030725, a program supervision framework for
x86-linux.
==9873== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==9873== Startup, with flags:
==9873== --suppressions=/usr/local/lib/valgrind/default.supp
==9873== --error-limit=no
==9873== --leak-check=yes
==9873== -v
==9873== --show-reachable=yes
==9873== Reading syms from /r2net/r2/fma/ITKTest/test/bin/fmatest
==9873== Reading syms from /lib/ld-2.2.4.so
==9873== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so
==9873== Reading syms from /usr/local/lib/valgrind/valgrind.so
==9873== Reading syms from /usr/local/lib/valgrind/libpthread.so
==9873== Reading syms from /lib/libdl-2.2.4.so
==9873== Reading syms from /lib/i686/libm-2.2.4.so
==9873== Reading syms from /usr/local/lib/libstdc++.so.5.0.5
==9873== Reading syms from /usr/local/lib/libgcc_s.so.1
==9873== Reading syms from /lib/i686/libc-2.2.4.so
==9873== Reading suppressions file: /usr/local/lib/valgrind/default.supp
==9873== Estimated CPU clock rate is 998 MHz
==9873==
Input volume: size (512 512 304) spacing (1.00 1.00 1.00) origin (0.00 0.00
0.00)
==9873== Warning: set address range perms: large range 159383552, a 0, v 0
Output volume: size (64 64 38) spacing (8.00 8.00 8.00) origin (0.00 0.00
0.00)
Resample successful
Watershed successful
==9873== Warning: set address range perms: large range 159383552, a 1, v 1
==9873==
==9873== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 78 from 2)
--9873--
--9873-- supp: 40 __pthread_mutex_unlock/_IO_funlockfile
--9873-- supp: 38 pthread_error/__pthread_mutex_destroy/_IO_default_finish
==9873== malloc/free: in use at exit: 11304 bytes in 14 blocks.
==9873== malloc/free: 2182 allocs, 2168 frees, 169816622 bytes allocated.
==9873==
==9873== searching for pointers to 14 not-freed blocks.
==9873== checked 6198744 bytes.
==9873==
==9873== 16 bytes in 1 blocks are definitely lost in loss record 1 of 5
==9873== at 0x4002C90D: malloc (vg_replace_malloc.c:153)
==9873== by 0x4002CE92: realloc (vg_replace_malloc.c:291)
==9873== by 0x403F5064: __argz_append (argz-append.c:30)
==9873== by 0x403923D6: __newlocale (newlocale.c:100)
==9873==
==9873==
==9873== 24 bytes in 2 blocks are definitely lost in loss record 2 of 5
==9873== at 0x4002CB02: __builtin_vec_new (vg_replace_malloc.c:197)
==9873== by 0x4002CB6D: operator new[](unsigned)
(vg_replace_malloc.c:210)
==9873== by 0x8158A56: vnl_c_vector_alloc(int, int)
(/space2/Devel/InsightToolkit-1.4.0/Utilities/vxl/vnl/vnl_c_vector.txx:362)
==9873== by 0x815892C: vnl_c_vector<double>::allocate_Tptr(int)
(/space2/Devel/InsightToolkit-1.4.0/Utilities/vxl/vnl/vnl_c_vector.txx:383)
==9873==
==9873==
==9873== 64 bytes in 1 blocks are still reachable in loss record 3 of 5
==9873== at 0x4002C90D: malloc (vg_replace_malloc.c:153)
==9873== by 0x403926BC: __newlocale (newlocale.c:162)
==9873== by 0x402F59AD:
std::locale::facet::_S_create_c_locale(__locale_struct*&, char const*,
__locale_struct*) (c++locale.cc:171)
==9873== by 0x402ED139: std::locale::_Impl::_Impl(std::locale::facet**,
unsigned, bool) (../../../../gcc-3.3.1/libstdc++-v3/src/localename.cc:226)
==9873==
==9873==
==9873== 11000 bytes in 9 blocks are still reachable in loss record 5 of 5
==9873== at 0x4002C9FD: __builtin_new (vg_replace_malloc.c:172)
==9873== by 0x4002CA68: operator new(unsigned) (vg_replace_malloc.c:185)
==9873== by 0x40332B2A: std::__default_alloc_template<true,
0>::_S_chunk_alloc(unsigned, int&)
(/r2/fma/gcc331Build/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_alloc.h:108)
==9873== by 0x40332A3C: std::__default_alloc_template<true,
0>::_S_refill(unsigned)
(/r2/fma/gcc331Build/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_alloc.h:550)
==9873==
==9873== LEAK SUMMARY:
==9873== definitely lost: 40 bytes in 3 blocks.
==9873== possibly lost: 0 bytes in 0 blocks.
==9873== still reachable: 11064 bytes in 10 blocks.
==9873== suppressed: 200 bytes in 1 blocks.
==9873==
--9873-- TT/TC: 0 tc sectors discarded.
--9873-- 11322 chainings, 0 unchainings.
--9873-- translate: new 17176 (264522 -> 3542893; ratio 133:10)
--9873-- discard 0 (0 -> 0; ratio 0:10).
--9873-- dispatch: 9126900000 jumps (bb entries), of which 3183030992 (34%)
were unchained.
--9873-- 182628/17242078 major/minor sched events. 17011469
tt_fast misses.
--9873-- reg-alloc: 3556 t-req-spill, 653228+18449 orig+spill uis, 85799
total-reg-r.
--9873-- sanity: 182629 cheap, 7306 expensive checks.
--9873-- ccalls: 87757 C calls, 59% saves+restores avoided (309252 bytes)
--9873-- 119583 args, avg 0.87 setup instrs each (30062 bytes)
--9873-- 0% clear the stack (263271 bytes)
--9873-- 28888 retvals, 30% of reg-reg movs avoided (16782 bytes)
>From: Luis Ibanez <luis . ibanez at kitware . com>
>To: Feng Ma <mafeng at hotmail . com>
>CC: insight-users at itk . org
>Subject: Re: [Insight-users] memory leak check in ITK?
>Date: Thu, 25 Sep 2003 22:49:36 -0400
>
>Hi Feng,
>
>
>Thanks for your report.
>
>There is a chance that a memory leak is taking
>place in this filter.
>
>
>Could you please try the following experiment:
>
>goto Insight/Code/Agorithms/itkWatershedSegmenter.txx
>
>and just before line 595 insert the following lines:
>
>
>--------------------------------------------
> if (m_Connectivity.index != 0)
> {
> delete[] m_Connectivity.index;
> }
>
> if (m_Connectivity.direction !=0 )
> {
> delete[] m_Connectivity.direction;
> }
>-------------------------------------------
>
>// then the code should continue with:
>
>
> m_Connectivity.index = new unsigned int[m_Connectivity.size];
> m_Connectivity.direction
> = new typename InputImageType::OffsetType[m_Connectivity.size];
>
>----------------------------------------------
>
>
>What may be happening is that the method GenerateConnectivity()
>is being called twice (or more). This method allocates memory
>for the direction and the index, but it is not checking if there
>were previous allocations.
>
>In the fix above, the potentially existing allocated
>memory is released before invoking "new" again.
>
>
>Please let us know if after inserting these lines, the
>report from Valgrind improves or not.
>
>It this happens to help, we will include this fix in the
>repository as soon as it is defrozen.
>
>
>
>
>Thanks,
>
>
> Luis
>
>
>
>------------------
>Feng Ma wrote:
>>Hi,
>>
>> I am using ITK and carefully checking memory leak in my project.
>>Wonderful what kind of memory checking tools ITK developers are using to
>>make sure no memory leakage.
>>
>> I am using valgrind to check my program, which performs watershed on an
>>input image. I got the memory leakage report from valgrind and posted
>>here. I am wondering if valgrind is capable enough to check ITK memory
>>allocation since ITK is pretty complicated and how much I should concern
>>with its report.
>>
>>
>>==7944== LEAK SUMMARY:
>>==7944== definitely lost: 64 bytes in 4 blocks.
>>==7944== possibly lost: 72 bytes in 1 blocks.
>>==7944== still reachable: 11064 bytes in 10 blocks.
>>==7944== suppressed: 200 bytes in 1 blocks.
>>==7944==
>>--7944-- TT/TC: 0 tc sectors discarded.
>>--7944-- 11330 chainings, 0 unchainings.
>>--7944-- translate: new 17170 (264458 -> 3541953; ratio 133:10)
>>--7944-- discard 0 (0 -> 0; ratio 0:10).
>>--7944-- dispatch: 9126900000 jumps (bb entries), of which 3185798345
>>(34%) were unchained.
>>--7944-- 182628/6169850 major/minor sched events. 5939243
>>tt_fast misses.
>>--7944-- reg-alloc: 3556 t-req-spill, 653056+18449 orig+spill uis, 85773
>>total-reg-r.
>>--7944-- sanity: 182629 cheap, 7306 expensive checks.
>>--7944-- ccalls: 87739 C calls, 59% saves+restores avoided (309178
>>bytes)
>>--7944-- 119561 args, avg 0.87 setup instrs each (30056 bytes)
>>--7944-- 0% clear the stack (263217 bytes)
>>--7944-- 28876 retvals, 30% of reg-reg movs avoided (16770
>>bytes)
>>
>>--7944-- supp: 40 __pthread_mutex_unlock/_IO_funlockfile
>>--7944-- supp: 38
>>pthread_error/__pthread_mutex_destroy/_IO_default_finish
>>==7944== malloc/free: in use at exit: 11400 bytes in 16 blocks.
>>==7944== malloc/free: 2182 allocs, 2166 frees, 169816622 bytes allocated.
>>==7944==
>>==7944== searching for pointers to 16 not-freed blocks.
>>==7944== checked 6201272 bytes.
>>==7944==
>>==7944== 16 bytes in 1 blocks are definitely lost in loss record 1 of 6
>>==7944== at 0x4002C90D: malloc (vg_replace_malloc.c:153)
>>==7944== by 0x4002CE92: realloc (vg_replace_malloc.c:291)
>>==7944== by 0x403F5064: __argz_append (argz-append.c:30)
>>==7944== by 0x403923D6: __newlocale (newlocale.c:100)
>>==7944== 48 bytes in 3 blocks are definitely lost in loss record 2 of 6
>>==7944== at 0x4002CB02: __builtin_vec_new (vg_replace_malloc.c:197)
>>==7944== by 0x4002CB6D: operator new[](unsigned)
>>(vg_replace_malloc.c:210)
>>==7944== by 0x810C020: itk::watershed::Segmenter<itk::Image<float,
>>3>::GenerateConnectivity()
>>(/r2/fma/ITK/1.4/Debug/include/InsightToolkit/Algorithms/itkWatershedSegmenter.txx:595)
>>
>>==7944== by 0x810A4C6: itk::watershed::Segmenter<itk::Image<float, 3>
>> >::GenerateData()
>>(/r2/fma/ITK/1.4/Debug/include/InsightToolkit/Algorithms/itkWatershedSegmenter.txx:178)
>>
>>==7944==
>>==7944==
>>==7944== 64 bytes in 1 blocks are still reachable in loss record 3 of 6
>>==7944== at 0x4002C90D: malloc (vg_replace_malloc.c:153)
>>==7944== by 0x403926BC: __newlocale (newlocale.c:162)
>>==7944== by 0x402F59AD:
>>std::locale::facet::_S_create_c_locale(__locale_struct*&, char const*,
>>__locale_struct*) (c++locale.cc:171)
>>==7944== by 0x402ED139: std::locale::_Impl::_Impl(std::locale::facet**,
>>unsigned, bool) (../../../../gcc-3.3.1/libstdc++-v3/src/localename.cc:226)
>>==7944==
>>==7944==
>>==7944== 72 bytes in 1 blocks are possibly lost in loss record 4 of 6
>>==7944== at 0x4002CB02: __builtin_vec_new (vg_replace_malloc.c:197)
>>==7944== by 0x4002CB6D: operator new[](unsigned)
>>(vg_replace_malloc.c:210)
>>==7944== by 0x810C049: itk::watershed::Segmenter<itk::Image<float, 3>
>> >::GenerateConnectivity()
>>(/r2/fma/ITK/1.4/Debug/include/InsightToolkit/Algorithms/itkWatershedSegmenter.txx:596)
>>
>>==7944== by 0x810A4C6: itk::watershed::Segmenter<itk::Image<float, 3>
>> >::GenerateData()
>>(/r2/fma/ITK/1.4/Debug/include/InsightToolkit/Algorithms/itkWatershedSegmenter.txx:178)
>>
>>==7944==
>>==7944==
>>==7944== 11000 bytes in 9 blocks are still reachable in loss record 6 of 6
>>==7944== at 0x4002C9FD: __builtin_new (vg_replace_malloc.c:172)
>>==7944== by 0x4002CA68: operator new(unsigned)
>>(vg_replace_malloc.c:185)
>>==7944== by 0x40332B2A: std::__default_alloc_template<true,
>>0>::_S_chunk_alloc(unsigned, int&)
>>(/r2/fma/gcc331Build/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_alloc.h:108)
>>
>>==7944== by 0x40332A3C: std::__default_alloc_template<true,
>>0>::_S_refill(unsigned)
>>(/r2/fma/gcc331Build/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_alloc.h:550)
>>
>>==7944==
>>
>> Thanks a lot in advance.
>>
>>-Feng
>>
>>_________________________________________________________________
>>High-speed Internet access as low as $29.95/month (depending on the local
>>service providers in your area). Click here. https://broadband . msn . com
>>
>>_______________________________________________
>>Insight-users mailing list
>>Insight-users at itk . org
>>http://www . itk . org/mailman/listinfo/insight-users
>>
>
>
>
>
_________________________________________________________________
Instant message during games with MSN Messenger 6.0. Download it now FREE!
http://msnmessenger-download . com