Memory warning after downloading and unzip files with ARC

Question

Im downloading some gzipped xml files from a server, save it to the documents folder and unzip every file. After that I delete the .gz file. I do that in a loop for more or less 500 files. When im using instruments, I see that the live bytes more or less are 470MB after this process. When Im waiting some seconds, the ARC clears it and the application is going to 5mb live bytes. But because its a synchronization process my app gets a memory warning right after that when I dont stop after the downloading and unzipping. At least I think it should be possible to force the ARC to release the memory? Or do I have a real bad code and I am just still dont see that?

Any help or hint is really appreciated.

Downloading and unzipping:

for(NSString *filePath in filePaths){
    NSString *localPath = [[DownloadManager sharedInstance] downloadFile:filePath];
    if(localPath){
        //downloaded correctly
        if([self unzipFileAtPath:localPath]){
            [FileUtility deleteFileAtPath:localPath];
        }
    }
}

Unzip method:

+ (BOOL)unzipFileAtPath:(NSString *)path
{
    NSData *gzData = [NSData dataWithContentsOfFile:path];
    NSData *ungzippedData = [gzData gunzippedData];

    BOOL success = [ungzippedData writeToFile:[FormatUtility pathWithoutGz:path] atomically:NO];
    ungzippedData = nil;
    gzData = nil;

    return success;
}

Answer 1

Wrap the inside of your for-loop with an autorelease pool :

for (NSString* filePath in filePaths) {
    @autoreleasepool {
        // do work
    }
}

The problem actually has nothing to do with ARC. Methods like dataWithContentsOfFile: will return a new autoreleased object instance. These objects will not be released until the enclosing autorelease pool is drained, which by default only happens at the end of your thread/operation or when you return to the run-loop.

When you allocate many temporary objects in a loop, like you're doing, you should use your own autorelease pool to ensure that these temporary objects do not accumulate needlessly.

Answer 2

I am facing a similar problem when downloading a very large zip file (of 5GB!) using AFNetworking 2.6.4 and AFDownloadRequestOperation 2.0.1. I find the such memory issue is caused by the Flipboard FLEX 2.1.1 framework. After I commented out the line [[FLEXManager sharedManager] setNetworkDebuggingEnabled:YES]; it works perfectly fine.