Edit AllPages

I’ve written some code which builds a quicktime movie ( and/or exports an image sequence ) from frames grabbed from OpenGL. The recording mechanism saves the framebuffer, raw, to a cache file in NSTemporaryDirectory and that works just fine.

The encoding phase extracts images one by one, flips them vertically, and then does whatever ( e.g., adding to the quicktime movie or saving to a numbered image in a sequence ). The encoding phase is threaded, performed by a fire and forget thread context as such:

Where saveSequenceOnThread: is implemented as such:

The TROUBLE here is that memory consumption grows linearly while the thread executes, sometimes peaking as high as 2 gigs when a long sequence is saved ( or a long movie is encoded ). When the thread terminates, and the NSAutoReleasePool is released, the memory is cleared, completely.

Commenting out the code that does the work, leaving only the calls to [imageSource nextFrame]; the memory still grows and isn’t released until the thread terminates, which implies to me the trouble is in my implementation of my ImageSource protocol which is below.

/* Called right before extracting images with nextImage. Image dimensions are already known. */

/* Called when done extracting images. */

As far as I can tell, I’m freeing up everything properly, though I might have missed something.

What I gather from this is that NSAutoReleasePool doesn’t really clean up memory until its released, itself. This is unacceptable! It’s unacceptable for NSAutoreleasePool to work as documented? Is there a message that can be sent to force NSAutoReleasePool to free pending frees immediately? Yes. [pool release]

Please, if anybody can help I’d appreciate it. This is disturbing.

For what it’s worth, I still get the memory leak when the thread does nothing except extract and then free the images. For example:


for the solution to this problem, and the ensuing discussion, see NSAutoreleasePool