Geek Answers Handbook

IPHONE: leak analysis with tools

I am trying to find leaks using tools, but the leaks that I see are similar to the ones in the following figure:

leaks

As you can see, there is no information about which line of code exactly flows. All the leaks that I have, about 20, look like this, or, in other words, the leaks do not show any line of my code in particular.

The leak in this illustration is related to "_CFAllocatorSystem" (???) on CoreFoundation, and I have others that just say GSEvent. I do not know what it is.

How can I find out?

Thanks for any help.

+2
source share
4 answers

I think you want to go to the tools after starting under the leak and select "Source View". Then you need to drag the source files into the tool window. Then it will display the lines in the code where the leak occurs and the call stack.

Some discard my leak code. This is similar to "Tools": alt text http://img688.imageshack.us/img688/9669/screenshot20091028at131.png

+1
source

What Leaks shows is a trace of the code that selects the object that is leaking (which means that it is saved, but your application does not have variables left with this address). What it does not show you is the place where the object was supposed to be released, so as not to cause a leak, because it is impossible to find out (you can find where the release is called, but it may not be so useful).

So what this trace says is that some of the memory allocated by the system is saved by you, and then the link is forgotten - one key is the string "PurpleEvent", which is normal in a thread associated with a timer event, or perhaps notifications. You could receive a notification and save something from it without releasing it later.

If you know at what point a leak occurs, you should be able to isolate code that runs during that time.

+1
source

See here and especially this quote:

This list informs you about the types, sizes and addresses of leaked objects and even their call stacks.

You can then trace the source of the memory leak through the call stack.

The stack trace shows which line is the culprit. Apparently line 14 in main.m is in your case. Do not know what you are confused about?

0
source

The fault was the accelerometer, and I'm compiling for OS 3.0.

In other words, the accelerometer that Apple said its leaks were fixed is still leaking like hell.
0
source

More articles:


All Articles