Allocation/Deallocation problems

[geforcefan]

Hallo Guys,

Since days, I am trying to figure out my "allocation/deallocation" problem. Its simple: I have a class called "Mesh". This is used for my OpenGL stuff.

Pseudo class Mesh:

class Mesh:
	vars:
	- std::vector<mathVector3> normals
	- std::vector<mathVector3> coordinates
	- std::vector<mathVector2> texture
	
	methods:
	- addVertex(mathVector3 _normals, mathVector3 _coordinates, mathVector2 _texture);
	- clear():
		normals.clear();
		coordinates.clear();
		texture.clear();
	- deconstructor:
		clear();

After I noticed that in my application are huge memory leaks, I began with debuging. For this, I wrote a "test application".

First I tried following (pseudo):

(breakpoint1) Mesh *TestMesh1 = new Mesh();
for(int i=0; i<100000; i++) TestMesh1 ->addVertex(mathVector3(0.0f), mathVector3(0.0f),mathVector2(0.0f));

(breakpoint2) while(1) break; // only for breakpoint

delete TestMesh1;

(breakpoint3) while(1) break; // only for breakpoint 

Now my RAM values for each breakpoint:

breakpoint1: 12.500 MB
breakpoint2: 59.800 MB
breakpoint3: 12.800 MB

Thats a difference of 300 kb. So 300 kb isnt deallocated. So I looked for a solution in the internet and read that "std::vectors needs a workaround".

The workaround is, to implement a "FreeAll" function, with a Template and using std::vector´s method "swap()".
So I added "FreeAll()" in my "Mesh" deconstructor before calling "clear()".

I repeated my test with breakpoints:

Same Result. 300 kb isnt been deallocated.

I am kind of frustrated, cause I dont know any solution for this. I think I missed something.

Why its important for me?

Because my Application is a "CAD-Program" which constantly changes Meshes (old Mesh is being deleted, and the new one allocated).

This is not about "not deallocationg 300 kb". Its about using not only one Mesh instance, there are hundreds of instances. There are constant changes for most of those Meshes: deallocations and allocations.

After a while, my App is allocating several GBs of RAM.

Any ideas?

- Ercan

[kbw]

What happens in addVertex?

[geforcefan]

Only:

addVertex(mathVector3 _normals, mathVector3 _coordinates, mathVector2 _texture):
	normals.push_back(_normals);
	coordinates.push_back(_coordinates);
	texture.push_back(_texture);

[kbw]

Can you show the typedef? I don't know if we're using values or pointers here.

[geforcefan]

Its a bit tricky:

mathVector3 is only a pseudo here.

I am using glm::vec3, its a part of OpenGL Mathematics (glm):

http://glm.g-truc.net/

I think they are only values, no pointers, but I am not sure about this. I didnt found anything about "deallocating" glm values. In the source (or header, because glm is header only lib) files, I also didnt found anything, that indicates a pointer. But not sure about this.

[kbw]

Maybe you white another test app that copied these glm objects around and check for leaks there.

Vectors don't do anything surprising and tend to highlight problems with the contained objects.

[geforcefan]

I also have tested by doing what you wrote. I dont think glm is the problem.

In the example in my opening post, I have a for statement, to push_back 100000 items of crap into the Mesh instance. Thats a huge amount of data. Thats nearly 50 MBs of data.

By deleting the instance, 300 KB is still remaining to be deleted. I cant image, glm let some crap left in the RAM. 300 KB crap from 100000 entries of items? If there would be 5-6 MBs left, I would image that.

Maybe I think wrong about this. I actually dont know.

Edit:

And again: I dont think glm is an object. They are only a collection of plenty templates and structs.

In other test by copying glm elements, they are beeing treatet like "non-objects with pointer stuff"

[coder777]

how do you come to this memory consumption values?

the os is not reliable in this regard. It might not give back especially small amounts of free memory due to avoiding fragemtation

You don't need to call clear() of the vector in your destructor since vector handles it already in it's destructor.

No, vector certainly doesn't leak

[geforcefan]

...small amounts of free memory due to avoiding fragemtation...

A Simple Test confirms my suspicion:

I am doing this test:

Mesh *TestMesh1 = new Mesh();
for(int i=0; i<100000; i++) TestMesh1 ->addVertex(mathVector3(0.0f), mathVector3(0.0f),mathVector2(0.0f));
delete TestMesh1;

While I am moving my cursor.

The amount of data is going up to the sky after several minutes, while doing the mouse movement constantly.

If u aks, it could be possible that the "MouseMovement" Event of my used Framework could causing this: No it cant. I also tested the MouseMovement Event without the code above.

However, how to avoid this? No chance to avoid this, because the os is avoiding fragmentation?

[coder777]

well, STL (so is vector) is part of the language specification. I doubt that there's a compiler that comes with a buggy implementation (not impossible, but very very unlikely)

vector cares only for it's own allocated memory. It will not free any other dynamic memory.
I don't know how your data looks like. If that leaks memory.

The os avoids fragmentation, but it doesn't hold the memory forever. It will however be available when needed.

once again: asking the os for it's free memory is not very reliable. Better use a memory detector such as this:

http://stackoverflow.com/questions/25730/what-is-the-best-free-memory-leak-detector-for-a-c-c-program-and-its-plug-in-d

[geforcefan]

Thank you for your link.

I am at the work at the moment, I will try it at home. If I find something neccerssary, I will report that due I find no solution for the leak.