Objective C/iPhone : need "best practices" for debugging memory management bugs

Question

So... I've written my first iPhone game, that consists of maybe 50 puzzles.

At the start of each puzzle I create some strings, various mutable arrays of pointers, some of which point to runtime created subviews. All retained variables are declared as various class properties. Then at the end of the puzzle I remove the subviews, release any memory allocated against pointers, nil my pointers. Then create them again for the next puzzle.

And the app runs great for the first 2, 3, sometimes 4 puzzles then crashes with seemingly random bad access errors etc that I'm struggling to track down. Obviously I'm not quite there with iPhone memory management :)

So, I need advice for debugging? Do you read through every line of code and make a note of every alloc, every subview, a kind of manual retain count? Do I search for allocs and match them to releases? Or are there other techniques?

I don't expect a reply as long as my question , but would any appreciate tips and tricks! Thanks!

Answer 1

Have you run the static analyzer over your code? That should catch most of these bugs. In the Xcode build options for your project, enable RUN_CLANG_STATIC_ANALYZER.

Answer 2

The static analyzer does a really good job of picking up retain leaks. I tend to use Apple Key A to build, which automatically does the analysis as part of the build.

The next step is to check out Instruments. I recommend running through you app in Instruments as part of your pre-submit process. You can track allocations while the app is running, check for leaks, performance testing etc.

Answer 3

As others have noted, the static analyzer helps a lot - in Snow Leopard you can just run "Build and Analyze" and read through the results.

I would say the next step would be instruments, but it seems more like your problem is early release of objects rather than leaking memory. To track down that, the best thing to do is to enable zombie detection.

In XCode, open up the "Executables" item in the project browser, right-click on your executable and select "Get Info". Then go to the "Arguments" tab, go to the bottom half and add a new environment variable. Name it "NSZombieEnabled" and set the value to "YES" - make sure it is checked as well, though it should be by default if you are creating it.

Now when you run the app, whenever you use an object that has been released the debugger will stop just before you get the BAD_ACCESS message, and you can see what is being released that should not be.

When you are done, you want to uncheck the NSZombieEnabled variable for your executable because the system will not really free any memory while it is set.

Debugging these things can be a little tricky because you have to figure out everywhere that released an object in order to find where it ended up being wrongly released. Snow Leopard Instruments helps with this, because Object Alloc works alongside NSZombieEnabled to show you a track of everywhere objects were released.

You can also use the "Leaks" tool to find places where you thought you had released objects but you really didn't - though I've found in practice that about half the time Leaks will not show anything because in addition to leaking, you kept a reference to the object around as well so Leaks doesn't know you really have a leak. It can be a really good idea to just watch the Object Alloc graph, and select regions that climb without releasing memory when you think they should.