FBO Memory Leak?

advanced
#1

I’ve been using a few FBO’s in my app, and have been finding that the app crashes after time.

One of the FBO’s gets cleared/allocated pretty frequently, and after using MallocDebug, I think that the allocate() method might be causing a memory leak. The strange thing is that MallocDebug doesn’t report it as a leak, but from watching the allocations I can see that it is there, because the memory it allocated stays there, even after the object goes out of scope.

It’s about 21k being used for every call to fbo.allocate(), and the calls that appear to be leaking are:

glCheckFramebufferStatusEXT (biggest hog)
glBindRenderbufferEXT
glBindTexture
glBindFramebufferEXT (barely any leaked)

I know for a fact that the FBO is being destroyed and its destructor is getting called, but still this memory seems to stay allocated.

Any ideas on the matter would be very useful! I am pretty new working with openGL textures and FBO’s.

Thanks!

#2

don’t know where’s the problem, but i suspect that is related to

http://forum.openframeworks.cc/t/fbo-memory-allocattion/2300/0

that is related to:

http://forum.openframeworks.cc/t/getting-an-error-message-when-closing-my-app—since-of0.06/2293/0

a delete that should be a delete[]

#3

hmm… thanks for the reply Arturo… I checked out my dynamic array allocations, and made sure they are all using delete [] for their clean up… but the app is still crashing after about 30 minutes of use.

#4

In my case I’m using some code from some Theo, on quad warpping, that I have modified to feet my needs. [I think it was from LaserTag. ofTextureAdv.cpp which is what lets you warp the texture]. I was not correctly deleting two arrays created in the “ofTextureAdv.cpp” - grid[] and coord[].

if this is not your problem, have you seen :

http://lists.apple.com/archives/mac-ope-…-00102.html
and
http://www.gamedev.net/community/forums-…–id=529380

not sure these links are helpful though.

#5

Ok, so to help debugging this, I’ve written a stand-alone app that isolates the problem.

All it does is clean/reallocate the FBO 4 times a second (every 15 frames @ 60 fps).

I’ve been testing it using MallocDebug and creating a Mark right at the start of execution. Showing “Allocations Since Mark” shows the memory being consumed as the FBO is reallocated, and seems to trace back to the 4 openGL functions I mentioned in my first post.

I’ve also tested it on a normal MacBook that has a different video card, and we see the same problem.

Any help would be sweet!

Thanks!

fboMemoryTest.zip

#6

well, i can easily replicate the leak on a pc as well.

for some reason though, i don’t see memory going up until the loop has run about 40 times or so.

#7

Try to replace the method clean() with this one in ofFBOTexture.cpp

  
  
void ofFBOTexture::clean()  
{  
	// try to free up the texture memory so we don't reallocate  
	// [http://www.opengl.org/documentation/specs/man-pages/hardcopy/GL/html/gl/deletetextures.html](http://www.opengl.org/documentation/specs/man-pages/hardcopy/GL/html/gl/deletetextures.html)  
	if (texData.textureName[0] != 0){  
		glDeleteFramebuffersEXT(1, &fbo);  
		glDeleteRenderbuffersEXT(1, &depthBuffer);  
		glDeleteTextures(1, (GLuint *)texData.textureName);  
	}  
	texData.width = 0;  
	texData.height = 0;  
	texData.bFlipTexture = false;  
}
#8

awesome.

I just tried this, ran 1000 iterations. On the original version, the app leaked 7 megs memory. With that change i measured less than 100k difference from when it launched.

problem solved. :smiley:

#9

Here is the most up to date FBO addon, and here is the location it will be maintained…

http://addons.openframeworks.cc/project-…-fbotexture

Your memory leak fix has been added, thanks!

Please test this addon and let me know if you find anything else.

#10

Awesome! Looks like it solved the problem! Thanks for the fix smallfly!