Finding hidden memory leak with Instruments
Using the 1 Mb NSDateFormatter memory leak as a case-study, this tutorial shows how to locate and isolate unexpected memory allocation using Instruments. Technically, this 1 Mb loss is arguably not a leak, since the data is cached, and is still actively referenced by the system. Yet…
Instruments has built-in tools to isolate true leaks (lost blocks) but can also be used to locate memory loss. While this session references iPhone OS 3.1.3, it can be generalized: only the example is specific, not the concept.
…as an engineer, I tend to differ: if every time I invoked a library API, I’d loose roughly 1 megabyte of RAM, I’d soon be running out of memory. I will also argue that, since this memory “cache” is neither documented nor explicitly reported it is, for all purposes, a leak(*).
(*) A leak is a lost block. But not all lost blocks qualify as leaks. This article focuses on the ones that don’t. Just like leaks, these lost blocks are consuming memory space. That space is generally not reclaimed until the host application quits.
1. Launch Instruments
From XCode, launch your application using “Object Allocations”
For this tutorial, we are not using Leaks Instrument Template. While Leaks is very effective against true leaks, it is oblivious to retained but forgotten objects, over-retained objects, or poor API implementation.
2. Run your application
In this example, only 32 seconds (about 0.54 minutes in Instruments notation) were needed to expose the unexpected memory usage.
It is a good idea to be generous in early scoping of memory usage, since it will fluctuate. For the purpose of this tutorial, this preliminary analysis phase has been skipped entirely.
3. Stop the Application execution
It has been established during other sessions that the particular memory consumption we are studying does not change during the lifetime of this application. Stopping it after 34 seconds.
Instruments can start/stop/save/restore sessions, which makes it invaluable to compare the program behavior before/after alterations.
4. Objects Created and Still Living
Focus on the objects that have been allocated, but not de-allocated.
Obviously, objects created but no longer living have been de-allocated, and are not of particular interest while searching for leaks.
5. Observe the Object Allocation Graph
Looking at the graph, it is easy to spot sudden memory allocation. For increased granularity, reduce the “Inspection Range”.
The Inspection Range will reduce the number of items present in the Diagram View below.
6. Set the View mode to Diagram View
7. Navigate the Diagram View
This is a very handy feature of Instruments. By sliding or dragging the time line cursor, the Diagram View selection will scroll accordingly. By bringing the triangular cursor precisely over the edge of the sharp raise of memory usage around the 0.54 min (32.5 seconds) area, one discovers pages and pages of a repeated call to -[NSDateFormatter getObjectValue:forString:range:error:]
8. Focus on the Diagram View
Observing the Diagram View, sorted either by “Responsible Caller” or by “Creation Time”, one can see the repeated invocation to the same NSDateFormatter method.
9. Call Stack
Turn on the call stack view (Extended Detail View)
10. Final analysis
By selecting a single line in the Diagram View, and inspecting the corresponding call stack in the Extended Detail View, one can focus on a single invocation and, hopefully, isolate the code responsible for the memory allocation. A double-click will jump to the source code, if available.
For example, +[Manager dateFromString] is the method responsible for invoking the suspicious NSDateFormatter -dateFromString selector.
Two facts will attract our attention:
- There are pages upon pages of NSDateFormatter invocations, all grouped together when sorted by Responsible Caller.
- When sorted by Creation Time, about 8000 invocations to NSDateFormatter take place within the same 100 ms.
When looked at closely, this study lead to a decision to not use NSDateFormatter time zones, which turned out to be the culprit.
11. Related links
Bookmark this on Delicious
