[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