I was first introduced to Instruments in the CS193P course that I took over the past few months. I found them to be invaluable for debugging memory leaks as I work on my Address Book iPhone app.
There are some good references on the Apple web site on using Instruments:
Debugging a real leak
One of the things you can look at in the Leaks Instrument is your Allocations. The instrument tracks how many bytes are living, allocated then released, etc.
There is documentation in the section on the Allocations Instrument for Displayed Information to tell you what the different columns mean.
I noticed that over time, the number of Live Bytes was increasing as I added test data to the Address Book. Suspecting a leak, I looked at the Leaks tab:
Sure enough, I had a leak that was occurring with multiple instances of a string.
By diving down into the leaked object, I was able to find the offending code fairly easily:
It turns out that for some reason adding information to the Organization property (kABPersonOrganizationProperty) in a new Address Book record is causing my problem. Knowing this I can look closer at this section of code to identify the problem.
I was first introduced to Heapshots after reading the excellent article:
A Heapshot is basically a snapshot of the state of your heap that shows growth since the previous Heapshot. I discovered that some increases in the heap in my application were not showing up as true leaks, yet they definitely represented memory that was being unexpectedly held onto.
I like to take a Heapshot when the Instrument is first fired up. I then take Heapshots periodically after some event occurs in my application.
Debugging with Heapshots
I noticed that I was seeing my heap unexpectedly grow at certain times. Ideally the Heap Growth should be 0 bytes after your application has reached a steady state.
With Heapshots you are able to dive into a specific Heapshot and look at the function call tree to help isolate the problem. In order to see the call tree, you must click on the right arrow to the immediate right of “Heapshot X”. If you click on a right arrow on one of the sub views, you will not see this call tree.
Once you’ve identified a good starting point in the function call tree, you can look at the associated code by double clicking the function name:
In one case I was able to trace issues to calls to UIImagePNGRepresentation() (UIImageJPEGRepresentation() had the same issue).
A search showed that others have had the same issue with these functions, though I haven’t seen a satisfactory solution yet: