[ITK-dev] there are some confusing memory leaks in ITK

[Matt McCormick]

Hello Micah,

Thank you for the report. Please use and report on the latest ITK 4.X,
since this is the focus of development efforts.

Thanks,
Matt


On Sun, Sep 20, 2015 at 5:32 AM, Micah Liu <micahliu2012 at gmail.com> wrote:
> Dear All,
>
> Yesterday I  build ITK project by using MFC frist time.
>
> It is weird.
>
> I only try to do such as:
>
> std::string szPathName = "...  ...";//get Dicom files Directory
> GDCMSeriesFileNames::Pointer spNamesGenerator = GDCMSeriesFileNames::New();
> spNamesGenerator->SetInputDirectory(szPathName);
>
> then end my program, which not any other operations. But the
> _CrtDumpMemoryLeaks dump so much blocks reporting memory leaks.
>
> I check ITK source code carefully. find it happen in following functions:
> ____________________________________________________________________
> void GDCMSeriesFileNames::SetInputDirectory (std::string const &name) , then
> into
> void SerieHelper::SetDirectory(std::string const &dir, bool recursive) ,then
> into
> void SerieHelper::AddFileName(std::string const &filename), then into
> bool File::Load( ) , then into
> bool Document::Load(  ),  then into
> bool Document::DoTheLoadingDocumentJob(  )  then into
> ... ... ... ...
> SeqEntry* DocEntrySet::NewSeqEntry(uint16_t group, uint16_t elem)
>
> finally, check NewSeqEntry function:
>
> SeqEntry* DocEntrySet::NewSeqEntry(uint16_t group, uint16_t elem)
> {
>    DictEntry *dictEntry = GetDictEntry(group, elem, "SQ");
>    gdcmAssertMacro(dictEntry);
>
>    SeqEntry *newEntry = new SeqEntry( dictEntry );
>    if (!newEntry)
>    {
>       gdcmWarningMacro( "Failed to allocate SeqEntry");
>       return 0;
>    }
>    return newEntry;
> }
>
>
>  _CrtDumpMemoryLeak tell me  "SeqEntry *newEntry = new SeqEntry( dictEntry
> );" make these leaks happen.
>
> but I check every relevant ITK code ,ITK don't do anything wrong , they
> release all that objects they need to release before   _CrtDumpMemoryLeak is
> called when program exit.
>
> So I confused.  There is any chance  that  _CrtDumpMemoryLeak make a mistake
> ?
>
> At last, I use Visual Leak Detector check it again. VLD give me something
> maybe valueable:
> ___________________________________________________________________
>   Leak Hash: 0x05D5522E, Count: 1, Total 16 bytes
>   Call Stack (TID 46040):
>     e:\program files (x86)\microsoft visual studio 11.0\vc\include\xmemory0
> (592): nodeItkLib.dll!std::allocator<std::_Container_proxy>::allocate
>     e:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring
> (671):
> nodeItkLib.dll!std::_String_alloc<0,std::_String_base_types<char,std::allocator<char>
>> >::_Alloc_proxy + 0xF bytes
>     e:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring
> (650):
> nodeItkLib.dll!std::_String_alloc<0,std::_String_base_types<char,std::allocator<char>
>> >::_String_alloc<0,std::_String_base_types<char,std::allocator<char> > > +
> 0xA bytes
>     e:\program files (x86)\microsoft visual studio 11.0\vc\include\xstring
> (749):
> nodeItkLib.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char>
>>::basic_string<char,std::char_traits<char>,std::allocator<char> > + 0x3E
> bytes
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\utilities\gdcm\src\gdcmdocentry.cxx
> (39): nodeItkLib.dll!gdcm::DocEntry::DocEntry + 0x57 bytes
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\utilities\gdcm\src\gdcmseqentry.cxx
> (40): nodeItkLib.dll!gdcm::SeqEntry::SeqEntry + 0x3B bytes
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\utilities\gdcm\src\gdcmdocentryset.cxx
> (526): nodeItkLib.dll!gdcm::DocEntrySet::NewSeqEntry + 0x2F bytes
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\utilities\gdcm\src\gdcmdocument.cxx
> (2404): nodeItkLib.dll!gdcm::Document::ReadNextDocEntry + 0x18 bytes
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\utilities\gdcm\src\gdcmdocument.cxx
> (1013): nodeItkLib.dll!gdcm::Document::ParseDES + 0xD bytes
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\utilities\gdcm\src\gdcmdocument.cxx
> (186): nodeItkLib.dll!gdcm::Document::DoTheLoadingDocumentJob
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\utilities\gdcm\src\gdcmdocument.cxx
> (123): nodeItkLib.dll!gdcm::Document::Load
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\utilities\gdcm\src\gdcmfile.cxx
> (151): nodeItkLib.dll!gdcm::File::Load + 0xA bytes
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\utilities\gdcm\src\gdcmseriehelper.cxx
> (99): nodeItkLib.dll!gdcm::SerieHelper::AddFileName
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\utilities\gdcm\src\gdcmseriehelper.cxx
> (249): nodeItkLib.dll!gdcm::SerieHelper::SetDirectory + 0x1D bytes
>
> e:\itk_vtk_dicom\i_vtk\itk320\insighttoolkit-3.20.1\code\io\itkgdcmseriesfilenames.cxx
> (82): nodeItkLib.dll!itk::GDCMSeriesFileNames::SetInputDirectory
>   ...  ...  ...  ...
>
>   Data:
>     00 89 82 04    00 00 00 00    00 00 00 00    00 00 00 00     ........
> ........
>
> ______________________________________________________
>
> above mensioned segment is one of VLD dumped. it is look like some leaks
> happen in SeqEntry's base class DocEntry,some STL string or list container.
> It's any possible that STL inside problem  lead to these upper leaks??? I
> guess... ...
>
> Anyway , I can't enough time to find the answer out by time limit for a
> project. If anybody understand what exactly happen here. pls kindly share
> with me. Thank a lot.
>
>
> Thanks & Bast Regards,
> Micah Liu
>
>
> _______________________________________________
> 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://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>