2

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.

Duck
  • 34,902
  • 47
  • 248
  • 470

4 Answers4

1

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.

Kendall Helmstetter Gelner
  • 74,769
  • 26
  • 128
  • 150
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

TechZen
  • 64,370
  • 15
  • 118
  • 145
0

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?

ennuikiller
  • 46,381
  • 14
  • 112
  • 137
  • sorry, but your answer do not shows any way to solve the problem. Have you clicked on the image I posted? My image is barely equal to yours and knowing the object type, size, address and call stacks do not helps to know what is generating this. – Duck Oct 27 '09 at 23:02
  • If you look at pretty much any iPhone project created with a template, main.m:14 is merely the line where the autorelease pool is emptied - it really means nothing as to the source of the leak, it's just a step along the way. – Kendall Helmstetter Gelner Oct 28 '09 at 01:53
  • and main.m:14 points to the whole application, something like, "there's a link on this app", but this, I know. – Duck Oct 28 '09 at 04:43
0

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.

Duck
  • 34,902
  • 47
  • 248
  • 470