Memory leaks in SMESH ?
Memory leaks in SMESH ?Posted by Roman Lygin at April 03. 2011
I am starting first steps with development using Salome (via the SMESH project at sourceforge which is based on 5.1.2).
The very first code:
boost::shared_ptr<SMESH_Gen> aGen (new SMESH_Gen());
boost::shared_ptr<SMESH_Mesh> aMesh (aGen->CreateMesh (0, true));
reveals memory leaks – many destructors of the internally created objects are just not called. For instance, empty destructor of SMESH_Gen does not destroy elements in _mapStudyContext, SMESH_Mesh destructor does not destroy its _myMeshDS and so on.
Here is the debug output:
- Trace ..\..\src\SMESH\SMESH_Gen.cpp  : SMESH_Gen::SMESH_Gen
- Trace ..\..\src\SMESH\SMESH_Gen.cpp  : SMESH_Gen::CreateMesh
- Trace ..\..\src\SMESH\SMESH_Mesh.cpp  : SMESH_Mesh::SMESH_Mesh(int localId)
- Trace ..\..\src\SMESH\SMESH_Mesh.cpp  : SMESH_Mesh::~SMESH_Mesh
- Trace ..\..\src\SMESH\SMESH_Gen.cpp  : SMESH_Gen::~SMESH_Gen
I have not run memory analysis with Intel Parallel Inspector to confirm suspicion but am pretty sure it will report leaks as, for instance, a breakpoint in destructor of SMESHDS_Mesh is not reached.
This sort of issues should have been caught years ago, so I rather assume I am making some mistakes, though two lines of the code above looks pretty straightforward too.
Does anybody have any clue on the issue?
Thank you in advance,
Re: Memory leaks in SMESH ?Posted by Edward AGAPOV at April 05. 2011
In SMESH, there is a higher level in the hierarchy of objects (SMESH_SRC/src/SMESH_I/*) that arranges the life cycle of the mesh according to application events. The mesh is explicitly destroyed when a dedicated study object dies.
Re: Memory leaks in SMESH ?Posted by Roman Lygin at April 05. 2011
Hi EAP (Edward?),
Thank you for the explanation and the reference. I have briefly looked into the SMESH_Gen_i and see that it brings some Corba-like overhead, which would be overwhelming in a non-Salome application. (I am currently investigating SMEH for CAD Exchanger). Secondly, SMESH_I is not part of the smesh project at Sourceforge (which is a subset of Salome) and Salome itself is not officially ported on Windows yet (though there is an experimental build from Erwan Adam).
So at this point, I a bit hesitate to step into the SMESH_I area. I will try to see what is possible to deal at the minimum level, perhaps looking at SMESH_I as a reference.
Re: Memory leaks in SMESH ?Posted by Roman Lygin at April 08. 2011
Running very basic code given here (http://salome-platform.org/forum/forum_11/257023341) on a shape attached in the same thread under Intel Parallel Inspector XE revealed memory leaks, as expected .
A couple of examples:
1. SMESH_subMesh *SMESH_Mesh::GetSubMesh()
aSubMesh = new SMESH_subMesh(index, this, _myMeshDS, aSubShape);
_mapSubMesh[index] = aSubMesh;
_mapSubMesh is never destroyed and hence all submeshes leak.
Given reference to SMESH_I above, I can't see how it can prevent leaks here. Sub-meshes are fully owned by SMESH_Mesh, so why would any external reference help ? Why isn't it part of the destructor?
Failure to destroy submeshes lead to other leaks related to resources controlled by submeshes (e.g. event listeners), e.g. allocated as follows:
void PropagationMgr::Set(SMESH_subMesh * submesh)
EventListenerData* data = new PropagationMgrData();
submesh->SetEventListener( getListener(), data, submesh );
Overall reading of Salome code and above memory leaks begs the following question. Why are plain pointers used in majority of places where smart pointers (boost::shared_ptr) would be a more reliable solution? This would eliminate needs to explicitly call delete and thus avoid head-ache of manual destruction.
Open CASCADE has been using handle (Handle_Standard_Transient subclasses) to reliably manage memory. Why did not Salome adopt similar approach with boost::shared_ptr ?