Understanding the Instrument for memory leak check

Question

Above given images is of my application leaks.

Here I want to understand that, in Extended Detail - you can see different colors like light green, light pink, light brown, light purple.

What does each color indicates?

Now the other confusion is "How to locate the code which is creating a memory leak?"

Upto what limit of memory leak - the actual iPhone can go on with. (suppose 10 bytes no problem, 20 bytes no problem & 200 bytes a problem)

• What does each color indicates?
• Which color indicates our code / From which detail we can get to the code where we have allocated the object & forgot to dealloc it?

(For example - On clicking of UIKit second cell in detail - we cant get to the code)

• Why we must resolve all the leaks? - even a single leak can chock up iPhone ?
• Why iPhone allows leaks to be remain in memory? / why garbage collection isn't done automatically after termination of application?
• If I try to dealloc objects which should be deallocated according to instruments, My application terminates abnormally. If I don't dealloc, My application runs perfectly, How?
• Why it is suggested that you wait in a view up to 10 or more seconds, if there is a leak, leak will be detected by Instruments?

Answer 1

The colors represent the different libraries the call stack is going through.

The leak is caused by the frame in your code that made the allocation, even if the actual allocation is taking place deep within an OS library. Instruments is showing you exactly where the leaked memory was allocated. You'll have to figure out which line in your code resulted in the leaked allocation, which will be one of the frames in the stack on the right.

The actual iPhone doesn't have much RAM available to your application. I tend to conservatively estimate about 25MB of RAM for my application to work with. Any leak, no matter how small, can sink the proverbial ship if the code is used enough.

Answer 2

I too have problems with leaks in instruments. I run my app today for the first time using leaks and found several leaks. Leaks that shouldn't be leaks because there is no way for them to leak, unless some magical code is executing and raising the retain count of my objects. I understand the memory management guidelines, know how to use autorelease pools, etc. But even an empty view based app contained leaks if i put a few controls on it. And just click around 2-3 times. Go ahead and try it. I don't really understant the information instruments is trying to provide. Are those "leaks" really leaks, or just things that are suspicious to the instruments app? Should an empty app with no user code, only a few controls put on an empty view leak memory?

Answer 3

Look for your application name in the stack extended view. Memory allocation usually shown in the end, so you know exactly which library is responsible for memory allocation. So you should trace from the line your code appear downwards till the end. Colors just make easier to trace lines of code, that are related to same libraries. Same library calls will be colored with the same color.

As for tracing leak itself. First go to your application call by double-click on the line in extended view and try to understand what exactly leaks. Sometimes you can replace the leaking call with non-leaking substitute. For example, I used a call imageNamed to retrieve images from the bundle, the application was constantly crashing because of memory shortage. I just googled imageNamed leaks and found very useful article on how to implement image cash in my application. Indeed, imageNamed API leaks. There are API that leaks in iphone SDK.

Also, try to check how you're working with alloc/retain/release and so on, whether you release or autorelease your allocated memory.

Good luck in your detective work.

Answer 4

First of all, the things in the stack are colored by which library they come from, so it doesn't contain that much information.

Second, instead of worrying about how much leakage the iPhone can take, I'd focus on not having it leak.

To find leaks, there are a couple options:

• Use the CLANG static analyzer when building your project
• Look for leaks manually. You must always follow The Rules of memory management: if you alloc, retain, or copy an object (including using @property (retain) or (copy)), you must release or autorelease it.

Answer 5

Ignore the colors, in that one the [DashBoard viewDidLoad] is the source of the leak, something in how it's initializing a URLConnection (possibly you did not free that when the connection was finished?)

Now to answer the other questions you had:

• Why we must resolve all the leaks? - even a single leak can chock up iPhone ?

Yes. Part of the reason is not only that you will simply run out of memory, but since there is only so much memory to go around for the whole phone a watchdog application is constantly monitoring your app and will shut it down early if it sees memory use only ever growing...

• Why iPhone allows leaks to be remain in memory? / why garbage collection isn't done automatically after termination of application?

All your application memory is freed when the app quits.

• If I try to dealloc objects which should be deallocated according to instruments, My application terminates abnormally. If I don't dealloc, My application runs perfectly, How?

Here I can't help, you really need to read more on the retain/release memory cycle... if you release an object that has a retain count of 0, the app crashes because the object is gone.

• Why it is suggested that you wait in a view up to 10 or more seconds, if there is a leak, leak will be detected by Instruments?

Because instruments works by sampling memory every so often, so it might take a little bit for instruments to get around to reading the memory after an action.