Learn Yourself to Debug Good With XCode and Instruments

by

Hi! (Here Roger pretends it hasn’t been 100 years since his last posting and moves on swiftly.) So if you’ve been learning or practicing iPhone development, you might agree with me that there’s one topic that inspires a little FUD and that is covered a little sparsely by books — debugging. Between scary messages like EXC_BAD_ACCESS, uncaught exceptions deep in the guts of thorny disassembled framework code, crashes that don’t break into the debugger, and the direct interface to the gdb console, debugging in XCode can have a learning curve even if you know your way around a debugger. I’ve seen too many good men use NSLog() to debug, and it bugs me.

So here’s a few screencasts I found around town on debugging, that I wanted to share. Do yourself a favor and watch them.

First up, a series of two screencasts by Jeff LaMarche on debugging basics. I’ll reiterate, even if it starts out basic, you might learn something since it seems everyone uses the debugger differently. Part One, Part Two. Key takeaways:

  • Dude. Just drag the breakpoint out of the gutter to remove it. I’ve been right-clicking the damn thing my whole life. Sighhh….
  • XCode breakpoints are heckuv powerful. Use symbolic breakpoints, conditional breakpoints, and breakpoint actions wisely.
  • Single most important thing: Add a symbolic breakpoint on objc_exception_throw. Newer XCode builds have a menu item for this in Run→Stop on Objective-C Exceptions.

Next, a screencast on debugging EXC_BAD_ACCESS, which is raised when you access an object that has vanished into thin air, most likely because you over-released it. This screencast from Mark Johnson shows you how to debug these errors with Instruments and NSZombies. You’ll see how to generate a complete history of any object, from allocation and including every release or retain. You’ll also see how to find the objects of interest by enabling zombies (you know, after your object is completely released and freed it sticks around, undead). For those of you who see Instruments and aren’t quite sure what to do with it, just watching Mark use it is helpful. My takeaway was that it’s much easier and nicer to use Instruments than to enable zombies by hand.

Finally, here’s a nice tutorial by Owen Goss on using Instruments to find memory leaks. It’s also another good scenario which you can follow to help get your head around Instruments.

Bonus info: XCode 3.2 and later has the Clang Static Analyzer built in. This is a sweet tool that analyzes your code without running it (thus the static part). Just run Build→Build and Analyze and you’ll get a brutal report of how and where Clang thinks your code is totally sketchy. John Muchow shows you how here.

Anything that still baffles you about XCode/iPhone debugging? Care to add any other beginner debugging help? Hit the comments!

  • majman

    more please

  • http://www.squarefrog.co.uk/ Paul

    Thank you thank you thank you for posting this!

    I just wrote my first app and crashed it on testing. Of course I just threw in a load of NSLog(); statements.. Wish I’d known about how amazing breakpoints are!

  • Amok

    Best post on the subject man!!
    Bookmarked without thinking twice!

  • Dylan Wilson

    I came across this article while trying to figure out exactly how Instruments worked and how I could use it to improve my code. I’ve been using NSLog(); and ignoring Instruments since I first started with XCode in 2009. Thanks to this post and the videos you linked to, I can actually properly debug any project I’m working on, rather than throwing it together, hoping it works, and hoping there’s not memory leaks.