[Insight-users] Help needed: memory Leak in ReconstructionByDilationImageFilter

qi yang tinaqiyang at gmail.com
Thu Sep 22 10:14:01 EDT 2011


Hi,

Thanks all for the useful suggestion.
Exactly like Dan pointed out, _CrtDumpMemoryLeaks() didn't correctly detect
the memory as ITK has not gone out of scope.
I did what Dan suggested, no more big memory leak is detected.

Thanks again for Dan and Richard's help! And sorry for wasting your time
with this stupid mistake.

Thanks,
Tina





On Wed, Sep 21, 2011 at 12:51 AM, Dan Mueller <dan.muel at gmail.com> wrote:

> Hi Tina,
>
> I'm not entirely sure how _CrtDumpMemoryLeaks() works, but ITK smart
> pointers work by deleting all non-referenced memory when they go out
> of scope. Looking at your code, I'm not 100% convinced the pointers
> have gone out of scope when you call _CrtDumpMemoryLeaks().
>
> Perhaps, just to make sure the ITK smart pointers are being given a
> chance to clean up, you could try the following:
>
> void DoWork() {
>  // Put your code here
> }
> int main() {
>  DoWork();
>  _CrtDumpMemoryLeaks();
> }
>
> -OR-
>
> int main() {
>  {
>  // Put your code here
>  }
>  _CrtDumpMemoryLeaks();
> }
>
> Cheers, Dan
>
> On 20 September 2011 17:40, qi yang <tinaqiyang at gmail.com> wrote:
> > Hi Richard,
> >
> > I tested on a simple version as following:
> >
> > #define _CRTDBG_MAP_ALLOC
> > #include <stdlib.h>
> > #include <crtdbg.h>
> > #include "itkImage.h"
> > #include "itkImageFileReader.h"
> > #include "itkImageFileWriter.h"
> > #include "itkReconstructionByDilationImageFilter.h"
> > int main()
> > {
> >  typedef unsigned char   PixelType;
> >  const unsigned int Dimension = 2;
> >  typedef itk::Image< PixelType, Dimension > ImageType;
> >  typedef itk::ImageFileReader< ImageType >  ReaderType;
> >  typedef itk::ImageFileWriter< ImageType >  WriterType;
> >
> >  const char  *inputFilenameMarker  = "C:\\work\\MeVisData\\marker.tif";
> >  const char  *inputFilenameMask  = "C:\\work\\MeVisData\\mask.tif";
> >     //const char  *outputFilename =
> "C:\\TYwork\\MeVisData\\ITKresult1.tif";
> >  // Get marker image
> >  ReaderType::Pointer reader = ReaderType::New();
> >  reader->SetFileName( inputFilenameMarker  );
> >  reader->Update();
> >  ImageType::Pointer markerImage = ImageType::New();
> >  markerImage = reader->GetOutput();
> >  markerImage->DisconnectPipeline();
> >
> >  // Get mask image
> >  //ReaderType::Pointer reader = ReaderType::New();
> >  reader->SetFileName( inputFilenameMask  );
> >  reader->Update();
> >  ImageType::Pointer maskImage = ImageType::New();
> >  maskImage = reader->GetOutput();
> >  //filter
> >  typedef itk::ReconstructionByDilationImageFilter<ImageType, ImageType>
> > FilterType;
> >  FilterType::Pointer filter = FilterType::New();
> >  filter->SetMarkerImage(markerImage);
> >  filter->SetMaskImage(maskImage);
> >  filter->Update();
> >
> >  _CrtDumpMemoryLeaks();
> > }
> >
> > Memory leak is still seen. The first memory leak size is the same as the
> > mask image.
> >
> > The memory leak log is as following:
> >
> > Detected memory leaks!
> > Dumping objects ->
> > {63766} normal block at 0x01F0DAD8, 147492 bytes long.
> >  Data: <                > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> > {63765} normal block at 0x01EE89B8, 4 bytes long.
> >  Data: <    > 00 00 00 00
> > {63733} normal block at 0x01EE89F8, 8 bytes long.
> >  Data: < W  8   > 80 57 EB 01 38 04 EC 01
> > {63731} normal block at 0x01EE8DB8, 4 bytes long.
> >  Data: <    > E0 87 EE 01
> > {63730} normal block at 0x01EE8938, 64 bytes long.
> >  Data: <,        Z      > 2C C5 9E 00 01 00 00 00 E8 5A C0 00 FF FF FF FF
> > {63669} normal block at 0x01EE87E0, 280 bytes long.
> >  Data: <        PV      > C4 BC 9E 00 01 00 00 00 50 56 C0 00 FF FF FF FF
> > {63608} normal block at 0x01EC0590, 9788 bytes long.
> >  Data: <4        V      > 34 96 9F 00 01 00 00 00 88 56 C0 00 FF FF FF FF
> > {63547} normal block at 0x01EC4660, 8 bytes long.
> >  Data: <l       > 6C 99 EE 01 00 00 00 00
> > {63546} normal block at 0x01EC0090, 8 bytes long.
> >  Data: <P       > 50 99 EE 01 00 00 00 00
> > {63545} normal block at 0x01EE9540, 8 bytes long.
> >  Data: <T       > 54 99 EE 01 00 00 00 00
> > {63544} normal block at 0x01EE96D8, 8 bytes long.
> >  Data: <8       > 38 99 EE 01 00 00 00 00
> > {63543} normal block at 0x01EE9900, 156 bytes long.
> >  Data: <        x[      > 8C B4 9E 00 01 00 00 00 78 5B C0 00 FF FF FF FF
> > {63353} normal block at 0x01EE9A78, 147492 bytes long.
> >  Data: <                > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> > {63340} normal block at 0x01EE8770, 52 bytes long.
> >  Data: <p   p   p       > 70 87 EE 01 70 87 EE 01 70 87 EE 01 CD CD CD CD
> > {63339} normal block at 0x01EE8728, 8 bytes long.
> >  Data: <h       > 68 A9 EB 01 00 00 00 00
> > {63338} normal block at 0x01EBA968, 20 bytes long.
> >  Data: <(       p       > 28 87 EE 01 CD CD CD CD 70 87 EE 01 00 00 00 00
> > {63337} normal block at 0x01EBA920, 8 bytes long.
> >  Data: <$   h   > 24 98 9F 00 68 A9 EB 01 ...
> > .......
> >
> > The callback log on "{63766} normal block at 0x01F0DAD8, 147492 bytes
> long"
> > is as following:
> >
> > msvcr100d.dll!_heap_alloc_dbg_impl(unsigned int nSize, int nBlockUse,
> const
> > char * szFileName, int nLine, int * errno_tmp)  Line 393 C++
> >   msvcr100d.dll!_nh_malloc_dbg_impl(unsigned int nSize, int nhFlag, int
> > nBlockUse, const char * szFileName, int nLine, int * errno_tmp)  Line 239
> +
> > 0x19 bytes C++
> >   msvcr100d.dll!_nh_malloc_dbg(unsigned int nSize, int nhFlag, int
> > nBlockUse, const char * szFileName, int nLine)  Line 302 + 0x1d bytes C++
> >   msvcr100d.dll!malloc(unsigned int nSize)  Line 56 + 0x15 bytes C++
> >   msvcr100d.dll!operator new(unsigned int size)  Line 59 + 0x9 bytes C++
> >   test.exe!operator new[](unsigned int count)  Line 6 + 0x9 bytes C++
> >   test.exe!itk::ImportImageContainer<unsigned long,unsigned
> > char>::AllocateElements(unsigned long size)  Line 178 + 0x9 bytes C++
> >   test.exe!itk::ImportImageContainer<unsigned long,unsigned
> > char>::Reserve(unsigned long size)  Line 86 + 0x13 bytes C++
> >   test.exe!itk::Image<unsigned char,2>::Allocate()  Line 52 C++
> >   test.exe!itk::ImageSource<itk::Image<unsigned char,2>
> >>::AllocateOutputs()  Line 216 + 0x26 bytes C++
> >   test.exe!itk::ReconstructionImageFilter<itk::Image<unsigned
> > char,2>,itk::Image<unsigned char,2>,std::greater<unsigned char>
> >>::GenerateData()  Line 112 + 0x12 bytes C++
> >   test.exe!itk::ProcessObject::UpdateOutputData(itk::DataObject *
> __formal)
> > Line 987 + 0x12 bytes C++
> >   test.exe!itk::DataObject::UpdateOutputData()  Line 420 + 0x21 bytes C++
> >   test.exe!itk::ImageBase<2>::UpdateOutputData()  Line 285 C++
> >   test.exe!itk::DataObject::Update()  Line 344 + 0xf bytes C++
> >   test.exe!itk::ProcessObject::Update()  Line 615 + 0x1c bytes C++
> >   test.exe!main()  Line 63 + 0x23 bytes C++
> >   test.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C
> >   test.exe!mainCRTStartup()  Line 371 C
> >   kernel32.dll!75ad3c45()
> >   [Frames below may be incorrect and/or missing, no symbols loaded for
> > kernel32.dll]
> >   ntdll.dll!775337f5()
> >   ntdll.dll!775337c8()
> >
> > I am new to ITK and it is really hard for me to detect where the leak is.
> >
> > Thank you!
> >
> >
> > Tina
> >
> >
> > On Mon, Sep 19, 2011 at 6:12 PM, Richard Beare <richard.beare at gmail.com>
> > wrote:
> >>
> >> Do you have minimalist version of your code that shows the leak?
> >>
> >> Line 112 is the AllocateOutputs() call, which is a standard part of
> >> most filters.
> >>
> >> On Tue, Sep 20, 2011 at 12:21 AM, qi yang <tinaqiyang at gmail.com> wrote:
> >> > Thanks for looking into this. I still haven't solved this issue.
> >> >
> >> > The following is the memory leak log from VS2010 output:
> >> >
> >> > Detected memory leaks!
> >> > Dumping objects ->
> >> > {769} normal block at 0x09F40040, 1208320 bytes long.
> >> >  Data: < P G P G P G P G> 00 50 C3 47 00 50 C3 47 00 50 C3 47 00 50 C3
> >> > 47
> >> > Object dump complete.
> >> >
> >> > Then I stopped at {769} where is the filter->update(), the call stack
> >> > log is
> >> > as following:
> >> >
> >> > msvcr100d.dll!_heap_alloc_dbg_impl(unsigned int nSize, int nBlockUse,
> >> > const
> >> > char * szFileName, int nLine, int * errno_tmp)  Line 393 C++
> >> >   msvcr100d.dll!_nh_malloc_dbg_impl(unsigned int nSize, int nhFlag,
> int
> >> > nBlockUse, const char * szFileName, int nLine, int * errno_tmp)  Line
> >> > 239 +
> >> > 0x19 bytes C++
> >> >   msvcr100d.dll!_nh_malloc_dbg(unsigned int nSize, int nhFlag, int
> >> > nBlockUse, const char * szFileName, int nLine)  Line 302 + 0x1d
> >> > bytes C++
> >> >   msvcr100d.dll!_malloc_dbg(unsigned int nSize, int nBlockUse, const
> >> > char *
> >> > szFileName, int nLine)  Line 160 + 0x1b bytes C++
> >> >   mfc100ud.dll!operator new(unsigned int nSize)  Line 321 + 0x10
> >> > bytes C++
> >> >   SA_Sgmt.exe!operator new[](unsigned int count)  Line 6 + 0x9
> bytes C++
> >> >   SA_Sgmt.exe!itk::ImportImageContainer<unsigned
> >> > long,float>::AllocateElements(unsigned long size)  Line 178 + 0x19
> >> > bytes C++
> >> >   SA_Sgmt.exe!itk::ImportImageContainer<unsigned
> >> > long,float>::Reserve(unsigned long size)  Line 86 + 0x13 bytes C++
> >> >   SA_Sgmt.exe!itk::Image<float,2>::Allocate()  Line 52 C++
> >> >   SA_Sgmt.exe!itk::ImageSource<itk::Image<float,2>
> >::AllocateOutputs()
> >> > Line 216 + 0x26 bytes C++
> >> >
> >> >
>   SA_Sgmt.exe!itk::ReconstructionImageFilter<itk::Image<float,2>,itk::Image<float,2>,std::greater<float>
> >> >>::GenerateData()  Line 112 + 0x12 bytes C++
> >> > When I commented the filter->update(), I don't see memory leak
> reported.
> >> >
> >> > I hope those information can give us more ideas.
> >> >
> >> > Thanks a lot,
> >> > Tina
> >> >
> >> >
> >> > On Sun, Sep 18, 2011 at 6:39 AM, Richard Beare <
> richard.beare at gmail.com>
> >> > wrote:
> >> >>
> >> >> I've run a couple of tests with the mac leak detector and didn't see
> >> >> anything.
> >> >>
> >> >> 2011/9/17 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> > The memory leak message is not more detailed than that?
> >> >> > I'm afraid we can't do much with that, unfortunately...
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Gaëtan
> >> >> >
> >> >> >
> >> >> > Le 14 sept. 11 à 18:11, qi yang a écrit :
> >> >> >
> >> >> >> Hi,
> >> >> >>
> >> >> >> I have a memory leaking problem bothered me for hours...
> >> >> >>
> >> >> >> My VS2010 detected a big memory leak after "filter->Update()" of
> >> >> >> ReconstructionByDilationImageFilter.
> >> >> >> The related code is as following:
> >> >> >> typedef itk::ReconstructionByDilationImageFilter<ImageType,
> >> >> >> ImageType>
> >> >> >> FilterType;
> >> >> >>
> >> >> >> FilterType::Pointer filter = FilterType::New();
> >> >> >>
> >> >> >> filter->SetMarkerImage(markerImage);
> >> >> >>
> >> >> >> filter->SetMaskImage(maskImage);
> >> >> >>
> >> >> >> filter->Update();
> >> >> >>
> >> >> >> Do I need to release something after using the filter? What's the
> >> >> >> related
> >> >> >> function?
> >> >> >>
> >> >> >> Thanks for any tips!!
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Tina
> >> >> >> _____________________________________
> >> >> >> Powered by www.kitware.com
> >> >> >>
> >> >> >> Visit other Kitware open-source projects at
> >> >> >> http://www.kitware.com/opensource/opensource.html
> >> >> >>
> >> >> >> Kitware offers ITK Training Courses, for more information visit:
> >> >> >> http://www.kitware.com/products/protraining.html
> >> >> >>
> >> >> >> Please keep messages on-topic and check the ITK FAQ at:
> >> >> >> http://www.itk.org/Wiki/ITK_FAQ
> >> >> >>
> >> >> >> Follow this link to subscribe/unsubscribe:
> >> >> >> http://www.itk.org/mailman/listinfo/insight-users
> >> >> >
> >> >> > --
> >> >> > Gaëtan Lehmann
> >> >> > Biologie du Développement et de la Reproduction
> >> >> > INRA de Jouy-en-Josas (France)
> >> >> > tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
> >> >> > http://mima2.jouy.inra.fr  http://www.itk.org
> >> >> > http://www.bepo.fr
> >> >> >
> >> >> >
> >> >> > _____________________________________
> >> >> > Powered by www.kitware.com
> >> >> >
> >> >> > Visit other Kitware open-source projects at
> >> >> > http://www.kitware.com/opensource/opensource.html
> >> >> >
> >> >> > Kitware offers ITK Training Courses, for more information visit:
> >> >> > http://www.kitware.com/products/protraining.html
> >> >> >
> >> >> > Please keep messages on-topic and check the ITK FAQ at:
> >> >> > http://www.itk.org/Wiki/ITK_FAQ
> >> >> >
> >> >> > Follow this link to subscribe/unsubscribe:
> >> >> > http://www.itk.org/mailman/listinfo/insight-users
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
> > _____________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Kitware offers ITK Training Courses, for more information visit:
> > http://www.kitware.com/products/protraining.html
> >
> > Please keep messages on-topic and check the ITK FAQ at:
> > http://www.itk.org/Wiki/ITK_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.itk.org/mailman/listinfo/insight-users
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20110922/62e60e74/attachment-0001.htm>


More information about the Insight-users mailing list