View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0022647Open CASCADEOCCT:Meshpublic2011-07-04 18:082012-11-09 09:56
ReportersanAssigned Tosan 
PrioritynormalSeveritytrivial 
Status closedResolutionfixed 
OSAll 
Product Version6.5.1 
Target Version6.5.2 
Summary0022647: Memory leak in BRepMesh_DiscretFactory
DescriptionThis problem can be reproduced with OCCT 6.5.1.

I have no idea how to check this easily with DRAW, but still I guess this could
be analyzed at the source code level.

I have noticed with help of the debugger, that when the following code is executed:

BRepMesh_PDiscretRoot&
  BRepMesh_DiscretFactory::Discret(const TopoDS_Shape& theShape,
                   const Standard_Real theDeflection,
                   const Standard_Real theAngle)
{
  myErrorStatus=BRepMesh_FE_NOERROR;
  Clear();

some BRep_TFace objects gets destroyed. Clear() method simply deletes the static
pointer to meshing algorithm (BRepMesh_IncrementalMesh in my case), and the base
class BRepMesh_DiscretRoot holds TopoDS_Shape (myShape field).
It means that BRepMesh_DiscretFactory indirectly holds a reference to the last
meshed shape, and this reference is released only on subsequent meshing
operation. Is it OK like this?

I can imagine a scenario when holding a static pointer to the meshing algo leads
to a memory leak:
1. A TopoDS_Shape object is created by the application.
2. Triangulation for the shape is built using BRepMesh_DiscretFactory (example:
Prs3d_ShadedShape class).
3. At some moment the application would like to delete the shape - but it
cannot! It is necessary to call BRepMesh_DiscretFactory::Clear() explicitly to
release the last reference to corresponding TShape.

I kindly ask someone who knows BRepMesh_DiscretFactory architecture well to
double-check if this is a real problem or I just misunderstand something.
TagsNo tags attached.
Test case numberNot needed

Attached Files

  • OCC22647.png (20,948 bytes)

Relationships

related to 0022600 closedbugmaster Community TBB has to be disabled in BRepMesh due to data races 

Activities

2011-07-04 16:31

 

OCC22647.png (20,948 bytes)

abv

2011-09-13 09:30

manager   ~0018105

Dear Sergey,

Could you please check current state of the SVN trunk (where fix for 22600 is integrated already) for whether the described problem have been eliminated by fix 22600, and if confirmed, switch this bug to solved / closed.

san

2011-09-13 11:16

developer   ~0018111

Hello,

I confirm that correction for 22600 has fixed also 22647.

Best regards,
Sergey

Issue History

Date Modified Username Field Change
2011-07-04 18:15 abv CC => kgv
2011-07-04 18:28 kgv OtherBugsDependingOnThis => 22600
2011-08-02 11:24 bugmaster Category OCCT:VIZ => OCCT:Visualization
2011-09-13 09:30 abv Note Added: 0018105
2011-09-13 09:30 abv Assigned To bugmaster => san
2011-09-13 09:30 abv Status new => feedback
2011-09-13 11:16 san Note Added: 0018111
2011-09-13 11:16 san Status feedback => assigned
2011-09-13 11:16 san Status assigned => reviewed
2011-09-13 11:17 san Status reviewed => closed
2011-09-13 11:17 san Resolution open => fixed
2011-09-13 11:17 san Fixed in Version EMPTY =>
2011-09-13 11:20 san Product Version => 6.5.1
2011-09-13 11:20 san Target Version => 6.5.2
2011-09-13 11:20 san Description Updated
2012-04-04 15:30 apn Test case number => Not needed
2012-11-09 09:56 abv Category OCCT:Visualization => OCCT:Mesh