[ITK-users] Possible memory leak in itk::IterativeTriangleCellSubdivisionQuadEdgeMeshFilter
Arnaud Gelas
arnaudgelas at gmail.com
Fri Jun 5 03:14:07 EDT 2015
Here is the patch:
http://review.source.kitware.com/#/c/19878/ <http://review.source.kitware.com/#/c/19878/>
I don’t have time right now, for that but it would also be good to make a similar test with Data (i.e. PointData and CellData) to make sure there are not similar memory leaks…
Best
Arnaud
> On 05 Jun 2015, at 08:27, Arnaud Gelas <arnaudgelas at gmail.com> wrote:
>
> Hi,
>
> Thanks for pointing out this problem!
>
> The real problem is not with itk::QuadEdgeMesh, but with itk::Mesh, if you just change the mesh type from itk::QuadEdgeMesh to itk::Mesh, you’ll also get memory leaks.
> It just happens, that CellsContainer memory is not released for the current mesh when doing a Graft on another one.
>
> I’ll submit a patch very soon to fix it, and add both of you as reviewer!
>
> Thanks
> Arnaud
>
>> On 04 Jun 2015, at 18:55, wanlin zhu <wanlin.zhu at outlook.com <mailto:wanlin.zhu at outlook.com>> wrote:
>>
>> I think the memory leak issue origined from QuadEdgeMesh,
>>
>> #include "itkQuadEdgeMesh.h"
>> #include "itkRegularSphereMeshSource.h"
>>
>>
>> typedef itk::QuadEdgeMesh< double, 3 > TMesh;
>> typedef itk::RegularSphereMeshSource< TMesh > TSource;
>>
>> int main(int argc, char ** argv)
>> {
>> TSource::Pointer source = TSource::New();
>> source->Update();
>> TSource::Pointer source1 = TSource::New();
>> source1->SetResolution(5);
>> source1->Update();
>> TMesh::Pointer mesh = source->GetOutput();
>> mesh->Graft( source1->GetOutput());
>>
>> return EXIT_SUCCESS;
>>
>> }
>>
>> It gives memory leak errors as well.
>>
>>
>>
>> wanlin
>>
>> > Date: Wed, 3 Jun 2015 09:49:33 -0700
>> > From: davis.vigneault at gmail.com <mailto:davis.vigneault at gmail.com>
>> > To: insight-users at itk.org <mailto:insight-users at itk.org>
>> > Subject: [ITK-users] Possible memory leak in itk::IterativeTriangleCellSubdivisionQuadEdgeMeshFilter
>> >
>> > All--
>> >
>> > I've been observing some erratic behavior in my program, which after some
>> > investigation I believe may be due to a memory leak in
>> > itk::IterativeTriangleCellSubdivisionQuadEdgeMeshFilter. I've copied below
>> > a minimal example which exhibits the problem, along with the output from
>> > valgrind showing 15,360 bytes lost in 128 blocks. Is anyone able to
>> > reproduce this issue? (Note that the 72,704 bytes still reachable is
>> > valgrind's fault
>> > <http://stackoverflow.com/questions/30376601/valgrind-memory-still-reachable-with-trivial-program-using-iostream <http://stackoverflow.com/questions/30376601/valgrind-memory-still-reachable-with-trivial-program-using-iostream>>
>> > , not ITK's).
>> >
>> > ///////////////////////////////////////
>> > // MINIMAL EXAMPLE //
>> > ///////////////////////////////////////
>> >
>> > #include "itkQuadEdgeMesh.h"
>> > #include "itkRegularSphereMeshSource.h"
>> > #include "itkLoopTriangleCellSubdivisionQuadEdgeMeshFilter.h"
>> > #include "itkIterativeTriangleCellSubdivisionQuadEdgeMeshFilter.h"
>> >
>> > typedef itk::QuadEdgeMesh< double, 3 > TMesh;
>> > typedef itk::RegularSphereMeshSource< TMesh > TSource;
>> > typedef itk::LoopTriangleCellSubdivisionQuadEdgeMeshFilter< TMesh, TMesh >
>> > TLoop;
>> > typedef itk::IterativeTriangleCellSubdivisionQuadEdgeMeshFilter< TMesh,
>> > TLoop > TSubdivide;
>> >
>> > int main(int argc, char ** argv)
>> > {
>> >
>> > TSource::Pointer source = TSource::New();
>> > TSubdivide::Pointer sub = TSubdivide::New();
>> > sub->SetInput( source->GetOutput() );
>> > sub->SetResolutionLevels( 1 );
>> > sub->Update();
>> >
>> > return EXIT_SUCCESS;
>> >
>> > }
>> >
>> > ////////////////////////////////////////
>> > // VALGRIND OUTPUT //
>> > ////////////////////////////////////////
>> >
>> > $ valgrind --leak-check=full ./dv-registration
>> > ==20328== Memcheck, a memory error detector
>> > ==20328== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
>> > ==20328== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
>> > ==20328== Command: ./dv-registration
>> > ==20328==
>> > ==20328==
>> > ==20328== HEAP SUMMARY:
>> > ==20328== in use at exit: 92,160 bytes in 257 blocks
>> > ==20328== total heap usage: 13,030 allocs, 12,773 frees, 879,010 bytes
>> > allocated
>> > ==20328==
>> > ==20328== 19,456 (15,360 direct, 4,096 indirect) bytes in 128 blocks are
>> > definitely lost in loss record 2 of 3
>> > ==20328== at 0x4C2B0A5: operator new(unsigned long)
>> > (vg_replace_malloc.c:324)
>> > ==20328== by 0x4984F8: itk::QuadEdgeMesh<double, 3u,
>> > itk::QuadEdgeMeshTraits<double, 3u, bool, bool, float, float>
>> > >::AddFace(itk::GeometricalQuadEdge<unsigned long, unsigned long, bool,
>> > bool, true>*) (in
>> > /home/davis/Developer/oxford/Stebbing_Method/SubTest/bin/dv-registration)
>> > ==20328== by 0x49926F: itk::QuadEdgeMesh<double, 3u,
>> > itk::QuadEdgeMeshTraits<double, 3u, bool, bool, float, float>
>> > >::AddFaceWithSecurePointList(std::vector<unsigned long,
>> > std::allocator<unsigned long> > const&, bool) (in
>> > /home/davis/Developer/oxford/Stebbing_Method/SubTest/bin/dv-registration)
>> > ==20328== by 0x49D0D5: void
>> > itk::CopyMeshToMeshCells<itk::QuadEdgeMesh<double, 3u,
>> > itk::QuadEdgeMeshTraits<double, 3u, bool, bool, float, float> >,
>> > itk::QuadEdgeMesh<double, 3u, itk::QuadEdgeMeshTraits<double, 3u, bool,
>> > bool, float, float> > >(itk::QuadEdgeMesh<double, 3u,
>> > itk::QuadEdgeMeshTraits<double, 3u, bool, bool, float, float> > const*,
>> > itk::QuadEdgeMesh<double, 3u, itk::QuadEdgeMeshTraits<double, 3u, bool,
>> > bool, float, float> >*) (in
>> > /home/davis/Developer/oxford/Stebbing_Method/SubTest/bin/dv-registration)
>> > ==20328== by 0x491766:
>> > itk::QuadEdgeMeshToQuadEdgeMeshFilter<itk::QuadEdgeMesh<double, 3u,
>> > itk::QuadEdgeMeshTraits<double, 3u, bool, bool, float, float> >,
>> > itk::QuadEdgeMesh<double, 3u, itk::QuadEdgeMeshTraits<double, 3u, bool,
>> > bool, float, float> > >::CopyInputMeshToOutputMeshCells() (in
>> > /home/davis/Developer/oxford/Stebbing_Method/SubTest/bin/dv-registration)
>> > ==20328== by 0x4916E2:
>> > itk::QuadEdgeMeshToQuadEdgeMeshFilter<itk::QuadEdgeMesh<double, 3u,
>> > itk::QuadEdgeMeshTraits<double, 3u, bool, bool, float, float> >,
>> > itk::QuadEdgeMesh<double, 3u, itk::QuadEdgeMeshTraits<double, 3u, bool,
>> > bool, float, float> > >::CopyInputMeshToOutputMeshGeometry() (in
>> > /home/davis/Developer/oxford/Stebbing_Method/SubTest/bin/dv-registration)
>> > ==20328== by 0x491063:
>> > itk::IterativeTriangleCellSubdivisionQuadEdgeMeshFilter<itk::QuadEdgeMesh<double,
>> > 3u, itk::QuadEdgeMeshTraits<double, 3u, bool, bool, float, float> >,
>> > itk::LoopTriangleCellSubdivisionQuadEdgeMeshFilter<itk::QuadEdgeMesh<double,
>> > 3u, itk::QuadEdgeMeshTraits<double, 3u, bool, bool, float, float> >,
>> > itk::QuadEdgeMesh<double, 3u, itk::QuadEdgeMeshTraits<double, 3u, bool,
>> > bool, float, float> > > >::GenerateData() (in
>> > /home/davis/Developer/oxford/Stebbing_Method/SubTest/bin/dv-registration)
>> > ==20328== by 0x4C578C:
>> > itk::ProcessObject::UpdateOutputData(itk::DataObject*) (in
>> > /home/davis/Developer/oxford/Stebbing_Method/SubTest/bin/dv-registration)
>> > ==20328== by 0x4866C6: main (in
>> > /home/davis/Developer/oxford/Stebbing_Method/SubTest/bin/dv-registration)
>> > ==20328==
>> > ==20328== LEAK SUMMARY:
>> > ==20328== definitely lost: 15,360 bytes in 128 blocks
>> > ==20328== indirectly lost: 4,096 bytes in 128 blocks
>> > ==20328== possibly lost: 0 bytes in 0 blocks
>> > ==20328== still reachable: 72,704 bytes in 1 blocks
>> > ==20328== suppressed: 0 bytes in 0 blocks
>> > ==20328== Reachable blocks (those to which a pointer was found) are not
>> > shown.
>> > ==20328== To see them, rerun with: --leak-check=full --show-leak-kinds=all
>> > ==20328==
>> > ==20328== For counts of detected and suppressed errors, rerun with: -v
>> > ==20328== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context: http://itk-insight-users.2283740.n2.nabble.com/Possible-memory-leak-in-itk-IterativeTriangleCellSubdivisionQuadEdgeMeshFilter-tp7587434.html <http://itk-insight-users.2283740.n2.nabble.com/Possible-memory-leak-in-itk-IterativeTriangleCellSubdivisionQuadEdgeMeshFilter-tp7587434.html>
>> > Sent from the ITK Insight Users mailing list archive at Nabble.com <http://nabble.com/>.
>> > _____________________________________
>> > Powered by www.kitware.com <http://www.kitware.com/>
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>> >
>> > Kitware offers ITK Training Courses, for more information visit:
>> > http://www.kitware.com/products/protraining.php <http://www.kitware.com/products/protraining.php>
>> >
>> > Please keep messages on-topic and check the ITK FAQ at:
>> > http://www.itk.org/Wiki/ITK_FAQ <http://www.itk.org/Wiki/ITK_FAQ>
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/insight-users <http://public.kitware.com/mailman/listinfo/insight-users>
>> _____________________________________
>> Powered by www.kitware.com <http://www.kitware.com/>
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://www.kitware.com/products/protraining.php <http://www.kitware.com/products/protraining.php>
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ <http://www.itk.org/Wiki/ITK_FAQ>
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/insight-users <http://public.kitware.com/mailman/listinfo/insight-users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20150605/b06633c5/attachment-0001.html>
More information about the Insight-users
mailing list