IPHONE: Analyzing leaks with instruments

Question

I am trying to locate leaks using instruments, but the leaks I see there are like the ones in the next picture:

leaks

As you can see there's no information of which line of code is exactly leaking. All leaks I have, around 20, are like this, or in other words, the leaks don't show any line of my code in particular.

The leak in this picture is related to "_CFAllocatorSystem" (???) on the CoreFoundation and I have others that simply say GSEvent. I have no clue of what's generating these.

How can I discover that?

thanks for any help.

Answer 1

I think you want to go into instruments after running under leak and select "Source View". Then you need to drag your source files into the instrument window. It will then show the lines in the code where the leak occurs along with the call stack.

Some toss off code of mine leaks a view. It looks like this in Instruments: alt text http://img688.imageshack.us/img688/9669/screenshot20091028at131.png

Answer 2

The thing that Leaks shows you is, the trace to the code that allocated the object that is leaking (which means it is retained but your application has no variables left that have that address). What it does not show you is just where the object should have been released to not cause the leak, for that is impossible to know (it is possible to find where release is currently being called, but that may not be so helpful).

So what this trace is telling me, is that some bit of memory allocated by the system is being retained by you, and then the reference forgotten - one key is the "PurpleEvent" line, which is common in a thread dealing with timer events or perhaps notifications. It could be you received a notification and kept something from it, without releasing it later on.

If you know about at what point the leak occurs, you should be able to isolate what code is running during that time.

Answer 3

See here and especially this quote:

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

Then you can trace the source of leaked memories through the call stacks.

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

Answer 4

The guilty was the accelerometer and I am compiling for OS 3.0.

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