Leaks when the app terminates

Should I handle leaks when the application terminates, or is it more efficient to let the system handle them? I'm thinking that the system will be reclaiming all the memory anyway, so wouldn't additional efforts to free it be overhead?


Quote by paxdiablo:

All of the operating systems that I have knowledge of will reclaim conventional memory that had been allocated. That's because the allocation generally comes from a processes private address space which will be reclaimed on exit.

As far I'm aware this also applies to iOS.

Apple might however reject your Application. Memory leaks alone are generally no reason to reject application, they might however be the drop that makes the bucket overflow. Proper memory management is good practice and should always be pursued.

There is no reason to try and free all memory when your app terminates.

Doing so is a waste of CPU cycles.

Certainly, you might need a "shutdown" phase that'll persist some state, but your code must also assume that the "shutdown" codepath may not be run.

The system will reclaim all resources allocated by an application when the app is terminated, regardless of how it is terminated.

In fact, the UIKit (iOS) and AppKit (OS X) both take lots of shortcuts during application termination that cause lots of memory to still be allocated when the app terminates. This is done exactly for responsiveness reasons; when the user requests an app to be quit, it should quit very quickly.

(And I can't really think of a modern multi-tasking, task isolating, OS that doesn't automatically reclaim resources on process termination.)

All applications (processes) run in their own private memory space. The operating system manages this and always knows exactly what 'physical' memory has been allocated to the process. When the process exits, it is able to completely recover all of the used memory.

Therefore, if your application is going to exit you don't need to do any memory management or cleanups (the same is true for file accesses or network connections and so forth, though in these cases it may be in your best interests to clean up).

However, your application should never 'leak' memory.

A leak is when you allocate a chunk of memory and then lose all references to it within your running program.

A singleton is not a leak and Instruments will not flag it as a leak.

So, if you have something like this:

static NSString *aStaticString = nil;

+ (void)aFunction {
    aStaticString = [[NSString alloc] initWithString:@"aFunction"];

This is not a leak. So lets say you also have another function:

+ (void)anotherFunction {
    aStaticString = [[NSString alloc] initWithString:@"anotherFunction"];

Now, assuming you're using ARC, calling these functions will not cause leaks. The compiler/runtime knows to manage the NSString allocations, and as the aStaticString variable changes, deallocates the old memory.

So given this, how do you get leaks? Generally it will be due to circular references. For example:

+ (void)aBadFunction {
    NSMutableDictionary *aDict = [[NSMutableDictionary alloc] init];
    [aDict addObject:aDict forKey:@"aCircularReference"];

Here, aDict is created (allocated), then a reference to itself is added to it. When the function returns, the memory gets leaked as your program no longer has any reference to the aDict variable (if the function gets called again a new completely different aDict variable will get created). Now normally ARC would ensure aDict gets deallocated when the function exits, but in this case it can't as there is a reference to it in the object itself.

Generally circular references like this are more complex, but the principle is the same.

You should always free memory, however, see comments below:

There is a difference between:

int main() {

    int* i = malloc(5);
    ... // do stuff here
    return 0; // i "leaked" here, not that serious, a lot of programmers will skip freeing `i` before return



int main() {

    int* i;
    for(int j = 0; j < 5000; j++)
        i = malloc(5); // you leaked 5 bytes 5000 times, very serious, DO NOT DO THIS
    // the 24KB here will most likely be reclaimed later, HOWEVER
    // what if j changes? what if you have more loops? you may run of memory, especially on an embedded device!
    ... // do stuff here
    return 0;


Just follow one single rule: never be concerned about overhead when dealing with proper C memory management (C coding conventions).

so do this:

int main() {

    int* i;
    for(int j = 0; j < 5000; j++) {
        i = malloc(5);
        ... // do stuff with i here
        free(i); // you are not leaking anything =D         
    ... // do stuff here
    return 0;

Need Your Help

Change popup calendar months language

javascript php

I'm trying somehow to replace clickDate english Jan, Dec and etc. to other language, but I can't find how, because I only got these scripts bellow. idate is in this format - 20150730 and fdate - 20...

iOS 7 TabBar Translucent issue

iphone objective-c ios7 uitabbar

I have an issue, when I set the translucent box off on a TabBar, there is something blocking some of my view.