Thu, 01/14/2016 - 05:30
I got memory leak when I use OpenCascade and got following memory issue.
How do I clean it up? I am not familiar with OpenCascade. Thanks for your help.
Joe
==6867== 40,168 bytes in 3 blocks are still reachable in loss record 785 of 793
==6867== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6867== by 0x181DBD5C: Standard_MMgrOpt::Allocate(unsigned long) (in /opt/3rdParty/occ6.3/lib/libTKernel.so.0.0.0)
==6867== by 0x181F0887: TCollection_BasicMap::BeginResize(int, int&, void*&, void*&) const (in /opt/3rdParty/occ6.3/lib/libTKernel.so.0.0.0)
==6867== by 0x15CFD61A: BRepMesh_IDMapOfNodeOfDataStructureOfDelaun::ReSize(int) (in /opt/3rdParty/occ6.3/lib/libTKMesh.so.0.0.0)
==6867== by 0x15CFD81D: BRepMesh_IDMapOfNodeOfDataStructureOfDelaun::Add(BRepMesh_Vertex const&, NCollection_List const&) (in /opt/3rdParty/occ6.3/lib/libTKMesh.so.0.0.0)
==6867== by 0x15CFDEDC: BRepMesh_IDMapOfNodeOfDataStructureOfDelaun::Assign(BRepMesh_IDMapOfNodeOfDataStructureOfDelaun const&) (in /opt/3rdParty/occ6.3/lib/libTKMesh.so.0.0.0)
==6867== by 0x15D201CD: BRepMesh_FastDiscret::Add(TopoDS_Face const&) (in /opt/3rdParty/occ6.3/lib/libTKMesh.so.0.0.0)
==6867== by 0x15D23424: BRepMesh_IncrementalMesh::Update(TopoDS_Face const&) (in /opt/3rdParty/occ6.3/lib/libTKMesh.so.0.0.0)
==6867== by 0x15D242C3: BRepMesh_IncrementalMesh::Update(TopoDS_Shape const&) (in /opt/3rdParty/occ6.3/lib/libTKMesh.so.0.0.0)
==6867== by 0x15D24B55: BRepMesh_IncrementalMesh::Perform() (in /opt/3rdParty/occ6.3/lib/libTKMesh.so.0.0.0)
==6867== by 0x15D24C6B: BRepMesh_IncrementalMesh::BRepMesh_IncrementalMesh(TopoDS_Shape const&, double, unsigned int, double) (in /opt/3rdParty/occ6.3/lib/libTKMesh.so.0.0.0)
Thu, 01/14/2016 - 21:02
This is on Ubuntu with occ 6.3.
I got some other leaks.
==15915== at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15915== by 0x17DB28E8: TColgp_Array1OfPnt::TColgp_Array1OfPnt(int, int) (in /opt/3rdParty/occ6.3/lib/libTKMath.so.0.0.0)
==15915== by 0x17DB73E5: TColgp_HArray1OfPnt::TColgp_HArray1OfPnt(int, int) (in /opt/3rdParty/occ6.3/lib/libTKMath.so.0.0.0)
==15915== by 0x178693EE: Geom_BSplineCurve::Geom_BSplineCurve(TColgp_Array1OfPnt const&, TColStd_Array1OfReal const&, TColStd_Array1OfInteger const&, int, unsigned int) (in /opt/3rdParty/occ6.3/lib/libTKG3d.so.0.0.0)
==15915== by 0x173C1BD9: GeomLib_MakeCurvefromApprox::Curve(int) const (in /opt/3rdParty/occ6.3/lib/libTKGeomBase.so.0.0.0)
==15915== by 0x173B6026: GeomLib::BuildCurve3d(double, Adaptor3d_CurveOnSurface&, double, double, Handle_Geom_Curve&, double&, double&, GeomAbs_Shape, int, int) (in /opt/3rdParty/occ6.3/lib/libTKGeomBase.so.0.0.0)
==15915== by 0x163D606B: BRepLib::BuildCurve3d(TopoDS_Edge const&, double, GeomAbs_Shape, int, int) (in /opt/3rdParty/occ6.3/lib/libTKTopAlgo.so.0.0.0)
==15915== by 0x15185FFA: ShapeBuild_Edge::BuildCurve3d(TopoDS_Edge const&) const (in /opt/3rdParty/occ6.3/lib/libTKShHealing.so.0.0.0)
==15915== by 0x151D1C2C: ShapeFix_Edge::FixAddCurve3d(TopoDS_Edge const&) (in /opt/3rdParty/occ6.3/lib/libTKShHealing.so.0.0.0)
==15915== by 0x15230634: ShapeFix_Wire::FixEdgeCurves() (in /opt/3rdParty/occ6.3/lib/libTKShHealing.so.0.0.0)
==15915== by 0x15231371: ShapeFix_Wire::Perform() (in /opt/3rdParty/occ6.3/lib/libTKShHealing.so.0.0.0)
==15915== by 0x151E516D: ShapeFix_Face::Perform() (in /opt/3rdParty/occ6.3/lib/libTKShHealing.so.0.0.0)
==15915== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15915== by 0x181DBD5C: Standard_MMgrOpt::Allocate(unsigned long) (in /opt/3rdParty/occ6.3/lib/libTKernel.so.0.0.0)
==15915== by 0x14599389: IGESGeom_GeneralModule::NewVoid(int, Handle_Standard_Transient&) const (in /opt/3rdParty/occ6.3/lib/libTKIGES.so.0.0.0)
==15915== by 0x14A9ECAD: Interface_FileReaderTool::RecognizeByLib(int, Interface_GeneralLib&, Interface_ReaderLib&, Handle_Interface_Check&, Handle_Standard_Transient&) const (in /opt/3rdParty/occ6.3/lib/libTKXSBase.so.0.0.0)
==15915== by 0x14500207: IGESData_IGESReaderTool::Recognize(int, Handle_Interface_Check&, Handle_Standard_Transient&) (in /opt/3rdParty/occ6.3/lib/libTKIGES.so.0.0.0)
==15915== by 0x14A9EEFF: Interface_FileReaderTool::SetEntities() (in /opt/3rdParty/occ6.3/lib/libTKXSBase.so.0.0.0)
==15915== by 0x1450040D: IGESData_IGESReaderTool::Prepare(Handle_IGESData_FileRecognizer const&) (in /opt/3rdParty/occ6.3/lib/libTKIGES.so.0.0.0)
==15915== by 0x14589C5C: IGESFile_Read(char*, Handle_IGESData_IGESModel const&, Handle_IGESData_Protocol const&, Handle_IGESData_FileRecognizer const&, unsigned int) (in /opt/3rdParty/occ6.3/lib/libTKIGES.so.0.0.0)
==15915== by 0x1458A64D: IGESFile_Read(char*, Handle_IGESData_IGESModel const&, Handle_IGESData_Protocol const&) (in /opt/3rdParty/occ6.3/lib/libTKIGES.so.0.0.0)
==15915== by 0x1460CCA8: IGESSelect_WorkLibrary::ReadFile(char const*, Handle_Interface_InterfaceModel&, Handle_Interface_Protocol const&) const (in /opt/3rdParty/occ6.3/lib/libTKIGES.so.0.0.0)
==15915== by 0x14A80BEE: IFSelect_WorkSession::ReadFile(char const*) (in /opt/3rdParty/occ6.3/lib/libTKXSBase.so.0.0.0)
==15915== by 0x14B17539: XSControl_Reader::ReadFile(char const*) (in /opt/3rdParty/occ6.3/lib/libTKXSBase.so.0.0.0)
Sat, 01/16/2016 - 02:08
The example code in the IGES doc does not have leaks
the source code I use is as follows: have leaks above with any iges files.
can anyone help?
#include "TopoDS_Shape.hxx"
#include "Handle_XCAFApp_Application.hxx"
#include "Handle_TDocStd_Document.hxx"
#include "XCAFApp_Application.hxx"
#include "IGESCAFControl_Reader.hxx"
#include "Handle_XCAFDoc_ShapeTool.hxx"
#include "Handle_XCAFDoc_ColorTool.hxx"
#include "TDF_LabelSequence.hxx"
#include "XCAFDoc_DocumentTool.hxx"
#include "XCAFDoc_ShapeTool.hxx"
#include "XCAFDoc_ColorTool.hxx"
#include "TDocStd_Document.hxx"
int main()
{
const char * filename = "francis.igs";
// Initiate a dummy XCAF Application to handle the IGES XCAF Document
static Handle_XCAFApp_Application dummy_app = XCAFApp_Application::GetApplication();
// Create an XCAF Document to contain the IGES file itself
Handle_TDocStd_Document iges_doc;
// Check if a IGES File is already open under this handle, if so, close it to prevent
// Segmentation Faults when trying to create a new document
if(dummy_app->NbDocuments() > 0)
{
dummy_app->GetDocument(1,iges_doc);
dummy_app->Close(iges_doc);
}
dummy_app->NewDocument ("IGES-XCAF",iges_doc);
IGESCAFControl_Reader reader;
Standard_Integer stat = reader.ReadFile((char*)filename);
// Enable transfer of colours
reader.SetColorMode(Standard_True);
reader.Transfer(iges_doc);
// Read in the shape(s) and the colours present in the IGES File
Handle_XCAFDoc_ShapeTool iges_shape_contents = XCAFDoc_DocumentTool::ShapeTool(iges_doc->Main());
Handle_XCAFDoc_ColorTool iges_colour_contents = XCAFDoc_DocumentTool::ColorTool(iges_doc->Main());
TDF_LabelSequence iges_shapes;
iges_shape_contents->GetShapes(iges_shapes);
// List out the available colours in the IGES File as Colour Names
TDF_LabelSequence all_colours;
iges_colour_contents->GetColors(all_colours);
TopoDS_Shape shape = reader.OneShape();
reader.ClearShapes();
return 0;
}
Sun, 01/17/2016 - 01:30
Valgrind complains:
Handle_PColgp_HArray1OfPnt poles; in PGeom_BSplineCurve is not cleaned up.
other varibales in this class
Handle_PColStd_HArray1OfReal weights;
Handle_PColStd_HArray1OfReal knots;
Handle_PColStd_HArray1OfInteger multiplicities;
do not have problems.
Anyone can help?
Mon, 01/18/2016 - 16:58
Dear joe,
These warnings most likely are false positives.
See for details the next discussions
http://www.opencascade.com/content/memory-leaks-1 and/or http://opencascade.blogspot.com/2011/06/is-my-memory-leaking-part1.html
Best regards
FSR
Mon, 01/18/2016 - 19:40
These are not only warnings. Because my application does have leak because of OpenCascade6.3 IGES and STEP readers.
What I tried was load an IGES file and delete it, then load another one and delete it again. I repeated this process
a few times and saw memory use keeps going up.
Upgrading to 6.8 solved the problem. Therefore, better not to use 6.3. Users who are currently using 6.3 should be aware of this issue.
Mon, 01/18/2016 - 00:05
OK, OpenCascade has its own memory management system.
But after Standard::Purge() is called, no help.
in my application opencascade is small part. After opencascade is applied, it will be deleted.
But the memory keeps going up after opencascade is used and deleted.
Mon, 01/18/2016 - 03:39
The problem is gone after I upgraded to 6.8