CODEWITHSUNDEEP
objective-ciosxcodeinstruments
Jon
Jon

Reputation: 40062

XCode/Instruments not showing memory leaks

I'm following the Stanford iOS development lectures and I have a Calculator brain class which has been alloc init in a controller but I haven't released it in the dealloc.

- (CalculatorBrain *)brain
{
    if (!brain) 
        brain = [[CalculatorBrain alloc] init];

    return brain;

}

I ran from XCode -> Run with Performance Tool and the app started and no leaks appeared, I then clicked the home button in the iOS Simulator and nothing, I then double clicked the home button and closed the app and still nothing.

I also did Build & Analyse and it didnt spot anything

Could you let me know why its not picking it up?

Upvotes: 9

Views: 3431

Answers (3)

Dietrich Epp
Dietrich Epp

Reputation: 213827

It appears as if there is no detectable leak. Look at this line:

brain = [[CalculatorBrain alloc] init];

As long as brain points to an object, that object won't be considered a "memory leak". If at some point you do this,

brain = nil;

Then the leak will register. Deallocating the container object will also achieve this, but are you sure it's being deallocated? (It won't be deallocated when your program exits, for example.)

The problem: Leak detectors cannot detect all memory leaks -- this is a mathematically proven fact. Most detectors only detect unreachable objects, and many leak detectors are especially susceptible to false negatives -- in C it is hard to tell the difference at runtime between a pointer and an integer.

Edit: It sounds like your application only ever creates one instance of the controller, which only creates one instance of CalculatorBrain. If you think about what a memory leak really is, you can define it as unused memory that your program does not release back to the operating system.

  • While the program is running, CalculatorBrain is always in use and therefore it is not a leak.
  • When the program exits, the operating system automatically reclaims all memory used by your process, therefore there cannot be any memory leaks after a program exits.

If you want to create a leak to see what it looks like, you could create a new CalculatorBrain multiple times while your program is running, but forget to release the unused versions. In this scenario, as your program runs, more and more instances of CalculatorBrain would accumulate. On iOS and other embedded systems, this will generally crash your program. On a modern 64 bit computer it will gradually fill up the available swap space until you run out of swap, address space, or some other resource -- causing the program to crash or making the system very unresponsive.

Standard practice is to not care about deallocating objects which are supposed to exist for the entire program's run.

Upvotes: 7

Andrea
Andrea

Reputation: 26383

Well... it's true that leaks can't detect all memory leaks, but let's say that you are doing this:

myIvarBrain=[self brain];

If you are giving it to an iVar (released in the dealloc of your class, and without accessors), actually there is no leak at all. The returned RC is one and it will be one since the deallocation of your class. If you don't release it in the dealloc, you should wait a dealloc of your class to see a memory leak. Does make sense?

Upvotes: 0

Anomie
Anomie

Reputation: 94844

The analyzer cannot find all memory leaks. As far as it is concerned, storing the instance into the ivar doesn't leak it from that method, and then in dealloc it doesn't realize that the ivar should be released. XCode 4 may have improved in this respect, I don't recall (I still use XCode 3 myself).

As for the performance tool, remember that an object won't be considered leaked until nothing holds a reference to it anymore. So even though your controller doesn't deallocate the brain, the brain won't be considered leaked until the controller is deallocated (or receives a brain transplant). Also, note that on *nix-like systems, memory allocations are automatically cleaned up on process exit. So it isn't really a leak if you allocate memory for objects that should exist for the lifetime of your process (e.g. the app delegate and anything it permanently holds on to) and rely on this behavior to free it on process exit.

Upvotes: 0

Related Questions