Assimp memory leak
I recently pushed my game engine into a memory leak test with valgrind; it actually told me that Mesh
~ 7000 bytes are leaking in my class ; weird thing that tells me this:
7,280 bytes in 1 blocks are definitely lost in loss record 391 of 393
==5639== at 0x4C2C100: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5639== by 0x598647E: ??? (in /usr/lib/libassimp.so.3.0.1264)
==5639== by 0x597F37D: ??? (in /usr/lib/libassimp.so.3.0.1264)
==5639== by 0x58139E5: ??? (in /usr/lib/libassimp.so.3.0.1264)
==5639== by 0x581E2B2: Assimp::Importer::ReadFile(char const*, unsigned int) (in /usr/lib/libassimp.so.3.0.1264)
==5639== by 0x40D71A: glDetail::CMesh::CMesh(char const*) (Mesh.cpp:49)
==5639== by 0x412FB5: _ZN9__gnu_cxx13new_allocatorIN8glDetail5CMeshEE9constructIS2_IRPKcEEEvPT_DpOT0_ (in /home/mattmatt/workspace/C++/alpha++/main-dev/eclipse/Alpha++/Debug/Alpha++)
So the question is: is Assimp responsible for the memory leak? Here is the part of the code in question:
CMesh::CMesh(const char* fileName){
Assimp::Importer importer;
const aiScene* scene = importer.ReadFile(fileName, aiProcess_Triangulate |
aiProcess_GenSmoothNormals |
aiProcess_FlipUVs |
aiProcess_CalcTangentSpace
);
if(!scene){
LOG_ERROR("Mesh", "ERROR LOADING MESH ! : CHECK THE SUPPORTED MODEL TYPES MODEL I OR THE FILE PATH !");
abort();
}
const aiMesh* model = scene->mMeshes[0];
std::vector<Vertex> vertices;
std::vector<unsigned int> indices;
const aiVector3D aiZeroVector(.0f, .0f, .0f);
IndexedModel out;
for(unsigned i = 0; i < model->mNumVertices; ++i)
{
const aiVector3D* pPos = &(model->mVertices[i]);
const aiVector3D* pNormal = &(model->mNormals[i]);
const aiVector3D* pTexCoord = model->HasTextureCoords(0) ? &(model->mTextureCoords[0][i]) : &aiZeroVector;
const aiVector3D* pTangent = &(model->mTangents[i]);
Vertex vert (
glm::vec3(pPos->x, pPos->y, pPos->z),///positions
glm::vec2(pTexCoord->x, pTexCoord->y),///UV coords
glm::vec3(pNormal->x, pNormal->y, pNormal->z),///normals
glm::vec3(pTangent->x, pTangent->y, pTangent->z)///tangents
);
vertices.push_back(vert);
out.positions.push_back(*vert.getPos());
out.texCoords.push_back(*vert.getTexCoord());
out.normals.push_back(*vert.getNormal());
out.tangents.push_back(*vert.getTangent());
}
for(unsigned i = 0; i < model->mNumFaces; ++i){
const aiFace& face = model->mFaces[i];
assert(face.mNumIndices == 3);
indices.push_back(face.mIndices[0]);
indices.push_back(face.mIndices[1]);
indices.push_back(face.mIndices[2]);
}
importer.FreeScene();
out.indices = indices;
initMesh(out);
}
full code for my mesh class can be viewed on this issue Memory leak in opengl Mesh class if needed :)
//////////////////////////// Important change //////////////////// ///////
I have highlighted the part of the code in which there were resource leaks:
Assimp::Importer importer;
const aiScene* scene = importer.ReadFile("res/Suzy.obj", aiProcess_Triangulate |
aiProcess_GenSmoothNormals |
aiProcess_FlipUVs |
aiProcess_CalcTangentSpace
);
if(!scene){
LOG_ERROR("Mesh", "ERROR LOADING MESH ! : CHECK THE SUPPORTED MODEL TYPES MODEL I OR THE FILE PATH !");
abort();
}
What do I need to change?
source to share
The documentation Importer::ReadFile(const char *, unsigned)
says:
If the call succeeds, the contents of the file are returned as a pointer to the aiScene object. The returned data is read-only, the importer retains ownership of the data and will destroy it on destruction.
Based on this, it looks like you are using the Assimp library correctly, but there is a memory leak problem in the library itself.
??? lines means no debug information is available. If this is indeed a real memory leak, it is very useful to have debug information to pinpoint exactly where the memory leak is occurring. Debug information is especially important in this case because Importer :: ReadFile () calls a non-virtual member BaseImporter::ReadFile(const Importer*, const std::string&, IOSystem*)
, which then calls the pure-virtual member BaseImporter::InternReadFile(const std::string&, aiScene*, IOSystem*)
. I would assume 0x58139E5 is BaseImporter :: ReadFile (). The stack frames outside of this will depend on which BaseImporter implementation was chosen by Importer :: ReadFile ().
On Fedora systems, debug information can be obtained by installing the appropriate debuginfo package whenever possible. Fedora provides the assimp-debuginfo package, which can be installed via:
sudo yum --enablerepo fedora-debuginfo, updates-debuginfo install assimp-debuginfo
On Ubuntu and Debian systems, debug information is obtained by installing - dbg package when available. Unfortunately, neither Debian 8 'Jessie' nor Ubuntu 15.04 'Vivid Vervet' offer the libassimp-dbg package.
You can try building Assimp from source using debug information. See Stack Overflow question Creating a symbol table for gdb with cmake for instructions on how to do this.
source to share