Understanding Memory Leak Check Tool - iPhone

Question

The above images are a leak of my application.

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

What does each color indicate?

Now another confusion: "How to find code that creates a memory leak?"

Let's say what is the limit of memory leak - the real iPhone can go on. (suppose that 10 bytes is not a problem, 20 bytes without problems and 200 bytes is a problem)

• What does each color indicate?
• What color does our code indicate / From what detail can we get to the code in which we selected the object and forgot to free it?

(For example - when clicking on the second UIKit cell in detail - we cannot get the code)

• Why should we eliminate all leaks? - Even one leak can clog the iPhone?
• Why does the iPhone allow memory to leak? / Why is garbage collection not automatically performed after the application terminates?
• If I try to free the objects that should be freed according to the tools, my application stopped abnormally. If I do not uninstall, My application works fine, How?
• Why are you encouraged to wait for 10 seconds or more, if there is a leak, the leak will be detected using tools?

Answer 1

Ignore the colors, in that [DashBoard viewDidLoad] is the source of the leak, something in how it initializes the URLConnection (maybe you didn’t release it when the connection was finished?)

Now, to answer the other questions you had:

• Why should we eliminate all leaks? - even one leak can clog the iPhone?

Yes. Part of the reason is not only that you simply run out of memory, but since there is so much memory left for the whole phone, the watchdog application constantly monitors your application and will close it earlier if it sees the memory usage only ever grows .. .

• Why does the iPhone avoid memory leaks? / Why is garbage collection not automatically performed after the application terminates?

All of your application memory is freed when the application exits.

• If I try to delete objects that should be freed according to the tools, My application ends abnormally. If I am not dealloc, my application runs fine, how?

Here I can’t help, you really need to know more about the save / release memory cycle ... if you release an object that has a value of 0, the application will work because the object is gone.

• Why is it assumed that you wait in up to 10 seconds or more, if there is a leak, the leak will be detected using tools?

Because the tools work with selective memory every so often, it may take a little time for the tools to bypass reading memory after the action.

Answer 2

First of all, things on the stack are painted from the library from which they come, so it does not contain so much information.

Secondly, instead of worrying about how many leaks iPhone might take, I would focus on not leaking.

To find leaks, there are several options:

• Use CLANG static analyzer when creating a project
• Look for leaks by hand. You should 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 .

Answer 3

Colors represent different libraries that the call stack passes into.

The leak is caused by a frame in the code that made the allocation, even if the actual distribution occurs deep inside the OS library. The tools show you exactly where the memory leak was allocated. You will need to find out which line in your code has leaked the highlight, which will be one of the frames in the stack on the right.

The actual iPhone does not have a lot of RAM available for your application. I usually conservatively estimate about 25 MB of RAM for my application for work. Any leak, no matter how small, can flood the notorious ship if the code is used enough.

Answer 4

Locate the application name in the expanded stack view. Memory allocation is usually shown at the end, so you know exactly which library is responsible for memory allocation. So you have to trace from the line that your code is displayed down to the end. Colors make it easy to trace lines of code associated with the same libraries. The same library calls will be painted in the same color.

As for the leak itself leak. First go to the application call by double-clicking the line in the advanced view and try to understand what exactly is leaking. Sometimes you can replace a leaking call with a non-fluid replacement. For example, I used the imageNamed call to retrieve images from a package, the application constantly crashes due to lack of memory. I just searched for GoogleName images and found a very useful article on how to implement the image in my application. Indeed, the imageNamed API. There is an API that runs in the iphone SDK.

Also, try checking how you work with alloc / keep / release, etc., regardless of whether you free or automatically save the allocated memory.

Good luck with your detective work.

Answer 5

I also have problems with leaks in tools. Today I run my application using leaks and have detected some leaks. Leaks that should not leak because they will not be able to leak if any magic code is not executed and does not increase the number of my objects. I understand the guidelines for memory management, I know how to use autostart pools, etc. But even an application with an empty view contains leaks if I put several controls on it. And just click about 2-3 times. Go and try. I do not quite understand what information tools are trying to provide. Are these "leaks" really leaks or just suspicious for the application tools? Should an empty application without user code, only a few controls place vision leaks in the empty memory?