[Insight-users] Help needed: memory Leak in ReconstructionByDilationImageFilter
Richard Beare
richard.beare at gmail.com
Tue Sep 20 21:15:16 EDT 2011
I'm confused as well. As I mentioned before, everything in the
reconstruction filter uses smart pointers and should be safe. I can
only speculate that something odd happens if the pipeline doesn't go
to a "sink" - try assigning to an image and doing the disconnect as
you did for the readers. As a further sanity check, try converting the
images to another format, such as the ITK meta format. The last
possibility I can think of is that perhaps the Graft() calls aren't
quite right in the reconstruction filter. I'll need to compare to
other examples.
On Wed, Sep 21, 2011 at 1:40 AM, 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
>> >> >
>> >> >
>> >
>> >
>
>
More information about the Insight-users
mailing list