Your message dated Wed, 23 Jun 2010 21:29:32 -0400
with message-id <[email protected]>
has caused the report #586915,
regarding ants: Memory leak and more
to be marked as having been forwarded to the upstream software
author(s) brian avants <[email protected]>
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
586915: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586915
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Hi Brian,
1st: would you advise me where to direct bug reports? I see
http://sourceforge.net/tracker/?group_id=232491&atid=1086078 but its
emptiness scares me (even if we forget my dispreference of all pure
browser-interface bug tracers).
Now let me introduce first bugreport from Debian user -- Michael (from
NeuroDebian, CCed ;)) alarmed me with:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586915
NB Usually we CC [email protected] whenever we forward bugreports
upstream. Please maintain CC so our "progress" in resolving this issue gets
protocoled.
So, division by 0 -- I've "patched" and committed, memory leak is more subtle
and I am not sure either it is not ITKs issue per se. Want to ask you. So the
major places at fault, according to valgrind:
==6170== 34,701,156 bytes in 1 blocks are indirectly lost in loss record 10 of
12
==6170== at 0x4C234CB: calloc (vg_replace_malloc.c:418)
==6170== by 0x8F1F65C: nifti_image_load (in /usr/lib/libITKniftiio.so.3.18.0)
==6170== by 0x52593EF: itk::NiftiImageIO::Read(void*) (in
/usr/lib/libITKIO.so.3.18.0)
==6170== by 0x4C87AE: itk::VectorImageFileReader<itk::Image<float, 3u>,
itk::Image<itk::Vector<float, 3u>, 3u>, itk::DefaultConvertPixelTraits<float>
>::GenerateData() (itkVectorImageFileReader.txx:540)
==6170== by 0x4F0275B:
itk::ProcessObject::UpdateOutputData(itk::DataObject*) (in
/usr/lib/libITKCommon.so.3.18.0)
==6170== by 0x4A57B5: itk::ImageBase<3u>::UpdateOutputData()
(itkImageBase.txx:280)
==6170== by 0x47B56F: void WarpImageMultiTransformFourD<4>(char*, char*,
std::vector<TRAN_OPT, std::allocator<TRAN_OPT> >&, MISC_OPT&)
(WarpTimeSeriesImageMultiTransform.cxx:659)
==6170== by 0x473279: main (WarpTimeSeriesImageMultiTransform.cxx:1000)
==6170==
==6170== 34,704,372 (2,784 direct, 34,701,588 indirect) bytes in 4 blocks are
definitely lost in loss record 11 of 12
==6170== at 0x4C234CB: calloc (vg_replace_malloc.c:418)
==6170== by 0x8F1D062: nifti_convert_nhdr2nim (in
/usr/lib/libITKniftiio.so.3.18.0)
==6170== by 0x8F20F18: nifti_image_read (in /usr/lib/libITKniftiio.so.3.18.0)
==6170== by 0x5258818: itk::NiftiImageIO::Read(void*) (in
/usr/lib/libITKIO.so.3.18.0)
==6170== by 0x4C87AE: itk::VectorImageFileReader<itk::Image<float, 3u>,
itk::Image<itk::Vector<float, 3u>, 3u>, itk::DefaultConvertPixelTraits<float>
>::GenerateData() (itkVectorImageFileReader.txx:540)
==6170== by 0x4F0275B:
itk::ProcessObject::UpdateOutputData(itk::DataObject*) (in
/usr/lib/libITKCommon.so.3.18.0)
==6170== by 0x4A57B5: itk::ImageBase<3u>::UpdateOutputData()
(itkImageBase.txx:280)
==6170== by 0x47B56F: void WarpImageMultiTransformFourD<4>(char*, char*,
std::vector<TRAN_OPT, std::allocator<TRAN_OPT> >&, MISC_OPT&)
(WarpTimeSeriesImageMultiTransform.cxx:659)
==6170== by 0x473279: main (WarpTimeSeriesImageMultiTransform.cxx:1000)
==6170==
==6170== 104,103,468 bytes in 3 blocks are possibly lost in loss record 12 of 12
==6170== at 0x4C234CB: calloc (vg_replace_malloc.c:418)
==6170== by 0x8F1F65C: nifti_image_load (in /usr/lib/libITKniftiio.so.3.18.0)
==6170== by 0x52593EF: itk::NiftiImageIO::Read(void*) (in
/usr/lib/libITKIO.so.3.18.0)
==6170== by 0x4C87AE: itk::VectorImageFileReader<itk::Image<float, 3u>,
itk::Image<itk::Vector<float, 3u>, 3u>, itk::DefaultConvertPixelTraits<float>
>::GenerateData() (itkVectorImageFileReader.txx:540)
==6170== by 0x4F0275B:
itk::ProcessObject::UpdateOutputData(itk::DataObject*) (in
/usr/lib/libITKCommon.so.3.18.0)
==6170== by 0x4A57B5: itk::ImageBase<3u>::UpdateOutputData()
(itkImageBase.txx:280)
==6170== by 0x47B56F: void WarpImageMultiTransformFourD<4>(char*, char*,
std::vector<TRAN_OPT, std::allocator<TRAN_OPT> >&, MISC_OPT&)
(WarpTimeSeriesImageMultiTransform.cxx:659)
==6170== by 0x473279: main (WarpTimeSeriesImageMultiTransform.cxx:1000)
==6170==
==6170== LEAK SUMMARY:
==6170== definitely lost: 4,352 bytes in 8 blocks
==6170== indirectly lost: 34,703,316 bytes in 25 blocks
==6170== possibly lost: 104,103,676 bytes in 6 blocks
==6170== still reachable: 80 bytes in 1 blocks
==6170== suppressed: 0 bytes in 0 blocks
That :659 seems to be call to ->Update() (how does it become
UpdateOutputData()? sorry I don't know ITK internals). If you think that
everything is quite legal on your side, I guess we should reassign this issue
to ITK (let them sweat if they decided to carry a copy of libnifti with changes
on top of released version which Michael has packaged).
Cheers,
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
--- End Message ---
