Personal tools
You are here: Home Forum How to use Salome? Memory leaks in SMESH ?

Memory leaks in SMESH ?

Up to How to use Salome?

Memory leaks in SMESH ?

Posted by Roman Lygin at April 03. 2011

Hello,

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 [53] : SMESH_Gen::SMESH_Gen

- Trace ..\..\src\SMESH\SMESH_Gen.cpp [109] : SMESH_Gen::CreateMesh

- Trace ..\..\src\SMESH\SMESH_Mesh.cpp [89] : SMESH_Mesh::SMESH_Mesh(int localId)

- Trace ..\..\src\SMESH\SMESH_Mesh.cpp [110] : SMESH_Mesh::~SMESH_Mesh

- Trace ..\..\src\SMESH\SMESH_Gen.cpp [67] : 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,

Roman

Re: Memory leaks in SMESH ?

Posted by Edward AGAPOV at April 05. 2011

Hi Roman

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.

Regards

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.

Thanks again,

Roman

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 ?

Thank you,

Roman

 

Powered by Ploneboard
Document Actions