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?
It appears as if there is no detectable leak. Look at this line:
As long as
brainpoints to an object, that object won’t be considered a “memory leak”. If at some point you do this,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.CalculatorBrainis always in use and therefore it is not a leak.If you want to create a leak to see what it looks like, you could create a new
CalculatorBrainmultiple times while your program is running, but forget to release the unused versions. In this scenario, as your program runs, more and more instances ofCalculatorBrainwould 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.