UIImagePickerController terminated due to Memory Pressure

Question

I have a UIViewController that has :

@property UIImagePickerController* mainPicker;

and with a button, I'm presenting that mainPicker like :

- (IBAction)takePhoto:(UIButton *)sender
{
// Take a photo.

    if(![UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypeCamera])
    {
    // No camera is available, show an alert.

        UIAlertView* newAlert = [[UIAlertView alloc] initWithTitle:@"Warning"
        message:@"Camera is not available." 
        delegate:self 
        cancelButtonTitle:@"OK" 
        otherButtonTitles:nil];

        [newAlert show];

        return;
    }

    if(mainPicker == nil)
    {
        mainPicker = [[UIImagePickerController alloc]init];

        mainPicker.delegate = self;
        mainPicker.allowsEditing = YES;  //I've tried without this line, didn't affect at all.
        mainPicker.sourceType = UIImagePickerControllerSourceTypeCamera;
    }

    [self presentViewController:mainPicker animated:YES completion:nil];
}

The first problem is ;

Snapshotting a view that has not been rendered results in an empty snapshot. 
Ensure your view has been rendered at least once before snapshotting or snapshot after screen updates.

Also, whenever that view controller is presented, there are at least two memory warnings.

After I take a photo, it gets worse. It's literally spamming "Received memory warning.".

Here is an Instrument screenshot, hope it would help.

The memory is about 4 MB at the beginning. After taking a photo, it goes up to 10 MB. While dismissing, I'm saving the UIImage, so it's nearly 30 MB after the dismissal. (That peak of the memory is probably caused by writeToFile:. Also, that leak there is about 600 bytes only).

Currently, I'm testing on iPhone 5S, with iOS 7.

I've tried enabling zombies, dispatching the picker after a while, allowing/disallowing editing, etc. None of them worked. Also, I'm not trying to present picker view instantly after loading the view controller.

Additional note, I've used the functions in the answer, and here is the logs;

Memory used  9588.7 (+9589), free 32063.5 kb
Memory used 10281.0 ( +692), free 18448.4 kb

Watching memory usage in iOS

Isn't it a bit weird to see 32 MB free memory in the device, whilst Instruments is telling another story?

Answer 1

Here are a few explanations to help you solve your problem.

First of all, the Zombies diagnostic tool is meant to debug crashes in which memory that was already freed is being accessed. This doesn't seem to be your problem here and thus the Zombies tool will be useless to you for this particular problem.

Second, the screenshot you have provided us is showing the Leaks instruments. The elements you see in that list are objects that your program has allocated and forgotten about without releasing them beforehand. This means that you do not have any single remaining pointer towards that memory that Instruments knows about. Fixing these leaks is a first step towards fixing your memory warnings.

Third, fixing your leaks probably won't be enough to fix your memory warning problems. These warnings indicate that you are using too much memory to iOS's liking. Considering your leaks account for a mere 600 bytes, the problem seems to be your abandoned memory. Abandoned memory is memory that you have allocated, and towards which you still have live references even though they probably won't ever be used again by your application.

In order to help you in fixing your problems, here is some relevant documentation to fix both memory leaks and abandoned memory using Instruments :
https://developer.apple.com/library/mac/recipes/Instruments_help_articles/FindingMemoryLeaksinYourApp/FindingMemoryLeaksinYourApp.html#//apple_ref/doc/uid/TP40012965-CH32-SW1
https://developer.apple.com/library/mac/recipes/Instruments_help_articles/FindingAbandonedMemory/FindingAbandonedMemory.html

Also, here is a useful blog post about abandoned memory : http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/