Find Memory Leaks

Introduction During a recent project upgrade, I used Instruments to investigate memory leaks. The results were quite revealing, so I'm documenting the process here. Instruments To make the most of Instruments, I went through Apple's relevant documentation to understand the proper approach for tracking down memory leaks. To Investigate a Leak Using the Call Tree 1. Open Instruments from within your Xcode project (so you can navigate directly to source code later), then find the Leaks instrument. 2. Select "New Trace Document" and click the Record button. 3. Use the app normally. 4. Watch the Leaks timeline — red blocks indicate memory leaks. 5. Click to display the call stack. Clicking the black triangle expands individual method calls. 6. Press to open the display settings. Enable and . The most recent calls will appear at the top. 7. Select the method call you want to investigate from the call stack. 8. Press to see memory usage for each method. 9. Double-click a method to view the corresponding source code. 10. Click the Xcode button to jump to the relevant code in Xcode. I haven't needed or yet, so I'll skip those for now. In practice, tracking through the call tree is sufficient to locate most memory leaks — and tracing the cause matters more than merely detecting leaks. Investigating the Code This memory leak looked alarming, but digging into it led to a basic networking library. I suspected it might be a false positive from Instruments. So I went looking for block retain cycles in the code. Still uneasy, I tracked the instance (manager). After the request instance was deallocated, the manager inside was indeed not being released. I searched Google for and found quite a bit of information: NSURLSession is holding a strong reference to its delegate (retain cycle) Possible memory leak in AFURLSessionManager The key point: holds a strong reference to its delegate. If you don't explicitly invalidate the session, it will leak memory. As mattt explains, when using AFNetworking, to terminate a session you need to call . Of course, if your entire app uses only a single session, this isn't necessary. The fix was to make the manager an instance variable and call in . Running Leaks again showed much less alarming results. This is one of the pitfalls introduced in AFNetworking 3.0. References Find Memory Leaks