Memory not returned properly
OS: Debian stretch (also tried on Linux mint 18) Boost 1.66, OSG 3.2.1, C++11
When generating geometry using GeometryConverter->convertGeometry, after loading an ifc model, the memory used by that model is not returned upon destruction. So if another model is loaded the memory will just keep to increment.
This is also true sometimes when generating only the ifc data using the IfcPPReaderSTEP.loadModelFromString method. Even if the shared_ptr<IfcPPModel> is destroyed, the memory is not released until the application terminates. I've removed everything else to eliminate other memory leaks in the app.
I tried using different versions of qt and openSceneGraph but without any luck (the versions mentioned in the installation guide).
Anyone else that have had similar issues? Might it be mismatches in third-party libraries?
Thanks Dennis Andersen
I haven't noticed a memory leak while using IFC++, but I might need to look closer. I am using it on Win10, x64 build with VS 2015
I am using it like this:
IfcPPReaderSTEP tReader;
std::shared_ptr<IfcPPModel> tModel(new IfcPPModel);
tReader.loadModelFromFile(tFileName, tModel);
GeometryConverter tConverter(tModel);
tConverter.convertGeometry();
//iterate over tConverter.getShapeInputData() and extract meshes into app
Maybe I have the time to look further in this issue and report back if I find something.
Small update: I tried my shot at heap debugging with the Microsoft C runtime. My tests did not indicate memory leaks during my usage of IFCPP.
I modified my code posted earlier with the following functions:
//additional includes and defines. Note that these should go FIRST
#define _CRTDBG_MAP_ALLOC
#define _CRTDBG_MAP_ALLOC_NEW
#include <crtdbg.h>
//other includes, functions, code...
auto tMemStateBefore = std::make_unique<_CrtMemState>();
{ //artificial scope to force all variables/shared_ptr to delete
IfcPPReaderSTEP tReader;
std::shared_ptr<IfcPPModel> tModel(new IfcPPModel);
tReader.loadModelFromFile(tFileName, tModel);
GeometryConverter tConverter(tModel);
tConverter.convertGeometry();
//iterate over tConverter.getShapeInputData() and extract meshes into app
}
_CrtMemDumpAllObjectsSince(tMemStateBefore.get());
The mem dump does not contain any items, which means that everything allocated was deleted. (I also took a look of the output if I move the dump into the scope to verify the function is working) I personally think it's reasonable to expect the same behaviour on Linux, as IFCPP primarily uses STL and Boost, but from your observations this doesn't seem to be the case.
You could try a build with debugging symbols + valgrind to find out more details about the source of the leaks, but at least on my platform/configuration I was unable to reproduce them.