Tips for finding and debugging abandoned memory and heap growth

Question

I recently watched one of the WWDC 2010 videos: Session 311 - Analyzing Extended Memory with Tools. Link here .

There is an interesting example in the video about searching for abandoned memory. It is said that debugging is often more important than leaks, but it can be more difficult.

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

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

The main way to find Abandoned memory is to take heaps using the Allocation tool.

However, after determining that I left the memory in my code, I found it really difficult to determine where it came from.

I am looking for some useful tips or resources for finding Abandoned memory.

Thanks!

Answer 1

In Tools, you can get a call stack for any object identified by the heap. Screenshot:

So, we have a far-fetched case where I allocate 1MB NSMutableData every time the user clicks a button. In an area with a central base, I have 4 heaps, and I have one expanded to show objects that were created but not released since the last heap. I highlighted a 1.25 MB non-object selection, and in the right pane it shows me the exact call stack in which this distribution occurred. One trick in this panel on the right is the slider at the bottom - it controls the elimination of stack frames. If you want to see all the frames of the stack, drag it to the right. Cut frames are those for which you do not have source code, and unoccupied frames are your code (or code that has both characters and a source.) (Also, if you don’t see the panel on the right, check the View buttons "on the toolbar.) What other information are you looking for?

Answer 2

To summarize, bbum is a great blog post :

• Profile your application with tools
• Use Distribution Template
• When the application is not running, click the small I next to the title of the Allocations track and note the number of sample counts ; this will let you know where the elements are stored, not just where they are highlighted.
• Launch the app, do something, and then return to the default state. For example, open a new document window and close it.
• Click the Mark Heap button in Tools.
• Repeat steps 4 and 5 several times.

When you view the distributions in the Tools, you can click the right arrow button to view the event history for this instance, including all the places that have been highlighted, saved, released, and autorealized.