Tips for finding and debugging abandoned memory an

问题:

I recently watched one of the WWDC 2010 videos: Session 311 - Advanced Memory Analysis with Instruments. The link is here.

There is an interesting example in the video on finding Abandoned Memory. They say that it is often more important to debug than leaks but can be more difficult.

Abandoned Memory is defined as "Accessible allocated memory that is never used again".

A leak is defined as "Allocated memory that can no longer be reached."

The primary way to find Abandoned Memory is to take heap shots using the Allocations instrument.

However, after determining that I have abandoned memory in my code, I have found that it is really difficult to find out exactly where it is coming from.

I am looking for some good tips or resources for finding Abandoned Memory.

Thanks!

回答1:

In Instruments, you can get a call stack for any object identified by a heapshot. Screenshot:

So what we've got here is a contrived case where I allocate a 1MB NSMutableData everytime the user taps a button. In the center-bottom pane, I've got 4 heapshots, and I have one expanded to show the objects that were created but not released since the last heapshot. I've highlighted a 1.25MB "non-object" allocation, and in the right pane, it shows me the exact call stack where this allocation occurred. One trick about that panel on the right is the slider along the bottom -- it controls the elimination of stack frames. If you want to see all the stack frames, drag it all the way to the right. Grayed out frames are those for which you don't have source code, and non-grayed-out frames are your code (or code you have both symbols and source for.) (Also, if you're not seeing the panel on the right, check the "View" buttons in the toolbar.) What other information are you looking for?

回答2:

To summarize bbum's excellent blog post:

1. Profile your app using Instruments
2. Use the Allocations template
3. When the app isn't running, click the little i next to the Allocations track header and check Record reference counts; this will let you know where the items are being retained, not just where they are allocated.
4. Run your app, do something, then return to a default state. For example, open a new document window, then close it.
5. Click the "Mark Heap" button in Instruments.
6. Repeat steps 4 and 5 several times.

When you review the allocations in Instruments, you can click the right-arrow button to see a history of events for that instance, including all places it was allocated, retained, released, and autoreleased.