Trimesh - leak memory

Question

I'm using the Trimesh library to compute the curvature on each vertex of a triangulated mesh. To do, I make:

 TriMesh *m = TriMesh::read(this->fichier);
m->need_curvatures();

float *degres= new float[nbr_vertices];

for(int i=0;i<nbr_vertices;i++)
 {
   degres[i]=m->curv1[i]; // get the curvature
 }

  delete [] degres;  m->clear(); delete m;

The problem is a leak memory detected even I clear and delete the "* m". The leak memory was detected by "valgrind".

this is the output of valgrind :

 912 bytes in 3 blocks are possibly lost in loss record 5 of 13
==4239==    at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4239==    by 0x4012E54: _dl_allocate_tls (dl-tls.c:296)
==4239==    by 0x5174DA0: pthread_create@@GLIBC_2.2.5 (allocatestack.c:589)
==4239==    by 0x599C905: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==4239==    by 0x4C67D2: trimesh::TriMesh::need_normals() (in /home/spin/spin)
==4239==    by 0x4B203D: trimesh::TriMesh::need_curvatures() 

Any idea to solve this issue ?

thanks.

Answer 1

912 bytes in 3 blocks are possibly lost in loss record 5 of 13

Possible loss might just be caching or pointer tricks and 912 bytes is hardly an issue. Unless it's several megabytes, I would ignore it, especially if its in a library snd not in your code.

For this to be an issue, it really should be something of a much larger magnitude, and generally a behaviour that grows with longer runs. If it were one kilobyte per call and you were doing it thousands or millions of times then it would need to be reported to the library creator

In short, no evidence of a real leak.

Run this in a loop and see if it grows significantly without settling off, otherwise you can ignore it.