ios memory going up very fast-Collection of common programming errors

The problem here is that you’re “busy-waiting” on adaptor.assetWriterInput.readyForMoreMediaData, — i.e. calling it over and over in a tight loop. This is, generally speaking, bad practice. The headers state that this property is Key-Value Observable, so you would be better off restructuring your code to listen for Key-Value change notifications in order to advance the overall process. Even worse, depending on how AVAssetInputWriter works (I’m not sure if it’s run-loop based or not), the act of busy-waiting here may actually prevent the asset input writer from doing any real work, since the run loop may be effectively deadlocked waiting for work to be done that might not happen until you let the run loop continue.

Now you may be asking yourself: How is busy-waiting causing memory pressure? It’s causing memory pressure because behind the scenes, readyForMoreMediaData is causing autoreleased objects to be allocated every time you call it. Because you busy-wait on this value, checking it over and over in a tight loop, it just allocates more and more objects, and they never get released, because the run loop never has a chance to pop the autorelease pool for you. (see below for more detail about what the allocations are really for) If you wanted to continue this (ill-advised) busy-waiting, you could mitigate your memory issue by doing something like this:

BOOL ready = NO;
do {
    @autoreleasepool {
        ready = adaptor.assetWriterInput.readyForMoreMediaData;
    }
} while (!ready);

This will cause any autoreleased objects created by readyForMoreMediaData to be released after each check. But really, you would be much better served in the long run by restructuring this code to avoid busy-waiting. If you absolutely must busy-wait, at least do something like usleep(500); on each pass of the loop, so you’re not thrashing the CPU as much. But don’t busy-wait.

EDIT: I also see that you wanted to understand how to figure this out from Instruments. Let me try to explain. Starting from the file you posted, here’s what I did:

I clicked on the Allocations row in the top pane Then I selected the “Created & Still Living” option (because if the things were getting destroyed, we wouldn’t be seeing heap growth.) Next, I applied a time filter by Option-dragging a small range in the big “ramp” that you see. At this point, the window looks like this:

Here I see that we have tons of very similar 4K malloc’ed objects in the list. This is the smoking gun. Now I select one of those, and expand the right pane of the window to show me a stack trace. At this point, the window looks like this:

In the right panel we see the stack trace where that object is being created, and we see that it’s being alloced way down in AVAssetInputWriter, but the first function below (visually above) the last frame in your code is -[AVAssetWriterInput isReadForMoreMediaData]. The autorelease in the backtrace there is a hint that this is related to autoreleased objects, and sitting in a tight loop like that, the standard autorelease mechanism never gets a chance to run (i.e. pop the current pool).

My conclusion from this stack is that something in -[AVAssetWriterInput isReadForMoreMediaData], (probably the _helper function in the next stack frame) does a [[foo retain] autorelease] before returning its result. The autorelease mechanism needs to keep track of all the things that have been autoreleased until the autorelease pool is popped/drained. In order to keep track those, it needs to allocate space for its “list of things waiting to be autoreleased”. That’s my guess as to why these are malloc blocks and not autoreleased objects. (i.e. there aren’t any objects being allocated, but rather just space to keep track of all the autorelease operations that have happened since the pool was pushed — of which there are MANY because you’re checking this property in a tight loop.)

That’s how I diagnosed the issue. Hopefully that will help you in the future.