Leaked Objects: ALasset and ALAssetPrivate

Question

I am using Profile to find any memory leaks.

I found 2 interesting leaks, which i can't understand:

Leaked Object |  Responsible Library | Responsible Frame

ALAsset         AssetsLibrary         [ALAssetsGroup _enumerateAssetsAtIndexes:options:usingBlock:]_block_invoke_0125

ALAssetPrivate  AssetsLibrary        -[ALAsset initWithManagedAsset:library:]

Is is my problem or AssetsLibrary? Are there any ideas how to fix this?

Answer 1

The problem lies in the Asset library itself. It contains a memory leak. Evidence is that the following code already shows a leak in the profiler (notice that I commented out the line where I added the asset to a mutable array):

[assetGroup enumerateAssetsUsingBlock:^(ALAsset *result, NSUInteger index, BOOL *stop) {         
        if(result == nil) {
            *stop = YES;
        } else {
            //[theAssets addObject:result];
        }
}];

A possible fix would be to check the retain count of the ALAsset pointer and release it yourself an extra time if the retain count is > 1 (it should be 1 at the end of the block if you have not retained it yourself).

EDIT:

I noticed the leak is actually an ALAssetPrivate object which is over-retained by ALAsset, the retain count of the ALAsset instance is correct.

EDIT:

Stupid me, the memory leak was actually caused by a category I implemented on ALAsset which included a dealloc method of itself. This was the cause of the leak.

Answer 2

Is is my problem or AssetsLibrary? Are there any ideas how to fix this?

Highly likely leaks are caused by your own code. The fact that Responsible Frame shows ALAsset only means that the memory was allocated in that library. But if you are the owner of that memory, you are responsible of the leak.

As to how to fix it, first of all, give a try to the static analyser in Xcode. That helps sometimes.

If it doesn't, the review how you use the AssetsLibrary or any intermediate framework that you are using to access it. Check all you properties, and each call to alloc/init or convenience constructors.

If you have no clue about where the leak might be produced, a useful technique is commenting out blocks of code selectively (of course, you should this in a sensible way, so that the app can run and not crash) and check again against Instruments until the leak disappears (in which case you know what was causing it).