Notes |
|
(0001356)
|
Luis Ibanez
|
2004-08-06 23:20
|
|
The destructor has now been declared virtual
(it wasn't despite the fact of having other virtual functions).
No the GeometryMap is visited and all its elements are erased with "delete". |
|
|
(0001360)
|
Luis Ibanez
|
2004-08-07 19:33
|
|
After fixing the GeometryMap container,
We found that there are additional memory leaks.
In order to see the full extent of the memory leak
the following command may be used with Valgrind
valgrind -v --leak-check=yes --leak-resolution=high ./SimplexMeshTest |
|
|
(0001929)
|
Lydia Ng
|
2005-01-14 13:40
|
|
|
|
(0009073)
|
Luis Ibanez
|
2007-09-18 11:19
|
|
Urgent to be addressed during WA10.
Setup Valgrind builds and review memory leaks reports. |
|
|
(0009074)
|
Luis Ibanez
|
2007-09-18 11:19
|
|
It is urgent to address the review of memory leaks. |
|
|
(0022655)
|
kentwilliams
|
2010-10-21 17:16
|
|
I built on a machine with Valgrind and ran all the SimplexMesh tests under valgrind. Only itksimplexMeshToTriangleMeshFilterTest reported leaks. I'm investigating fixing this. |
|
|
(0022656)
|
kentwilliams
|
2010-10-21 17:40
|
|
I am suspecting that the memory leaks reported in itkSimplexMeshToTriangleMeshFilterTest are false positives. They all have to do with the use of the member variable m_NewSimplexCellPointer, which is a member of itk::SimplexMeshAdaptTopologyFilter and itk::TriangleMeshToSimplexMeshFilter. In both cases, objects are allocated with new and assigned to this variable via its TakeOwnership method.
So either the AutoPointer class doesn't work or valgrind is confused. |
|
|
(0022679)
|
kentwilliams
|
2010-10-25 15:11
|
|
The problem with the itkSimplexMeshToTriangleMeshFilterTest doesn't make any sense; if I add this:
originalTriangleMesh = 0;
simplexFilter = 0;
To the bottom of that test, the memory errors go away. |
|
|
(0022681)
|
kentwilliams
|
2010-10-25 15:39
|
|
|