Advanced Breakpoints

Chris Hanson discusses Xcode’s advanced breakpoints today.

One very important feature of the advanced breakpoints found within Xcode is the ability to cause something to happen in the debugger — play a sound, print some data, run some AppleScript or invoke a shell script — without interrupting the application being debugged beyond stopping it briefly to take whatever action is specified in the breakpoint.

For debugging stuff like drag-n-drop, mouse tracking, and other human-computer-interaction related functionality, being able to break, take action, and continue the application without de-activating the application or otherwise messing with the context of event processing is absolutely critical.

In modern applications, the challenges of debugging are often not about which line of code is broken, but a matter of figuring out which of the 100,000 executions of a particular line of code is broken. Worse, the line of code is generally going to be invoked along one of many paths, often further convoluted by the code’s presence within a class hierarchy such that invocation is determined by state or customization applied by subclasses.

printf style debugging is often derided as an amateurish approach to figuring out what is going on. And it does suck. But it is often the only way to really figure out what is going on.

Until now. I’m finding that I will configure a breakpoint to log-and-continue. Once I figure out what offensive value is at the root of a problem, I can easily configure the breakpoint to no longer continue and to only stop when that value is present.

End result; no more stop/print/continue by hand with the debugger constantly futzing with the event processing context of the application.

Very, very useful.

4 Responses to “Advanced Breakpoints”

  1. GideonS says:

    Who derides printfs as a debugging tool? Sweet jesus. I work on video games and printf style logging is crucial. Especially when debugging networked client/server apps where the code maybe have timeout periods for the remote entity.

    Only a jackass would make a sweeping statement about printfs being bad for debugging.

  2. keith ray says:

    printfs are _so_ 1970’s… 🙂

  3. bbum says:

    I didn’t say I deride printf style debugging, just that some do. And, certainly, it is the only way to do so in many cases. But it does suck that you have to recompile and modify code to do printf debugging and the breakpoint actions generally solve that particular problem quite nicely.

  4. GideonS says:

    Yeah man, you’re cool. I got the whole “some” vibe, don’t worry. That’s why I started with the question: “Who derides..” Point me in their direction. 🙂
    I’m with you that printf debugging isn’t the happiest of all places to be. MS revved their 360 compiler a bit ago and removed watch points. That definitely cramped my style and required added some more hot printf action.
    I’m psyched to check out these breakpoint actions in xcode this weekend at home.

Leave a Reply

Line and paragraph breaks automatic.
XHTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>