Introduction to Xcode’s Debugger

December 18th, 2006

Filed under: Xcode | 7 comments

Most of you are familiar with the material in this article, but I read a lot of programming questions on message boards that could have been answered by running the code in a debugger. I hope new programmers will be able to find this article and use it to learn how to debug their programs.

What is a Debugger?

Computers run programs fast, which is normally a good thing. But if you have a problem in your code, the code runs too fast for you to figure out what is wrong. It’s like trying to watch a DVD in fast forward mode.

A debugger lets you slow things down so you can see what is happening when your program runs. By using a debugger you can pause your program at any line of code, step through your code line by line, and examine the values of your program’s variables. A debugger helps immensely when you’re trying to find out what’s wrong with your code. If you’re serious about being a software developer, one of the best things you can do is learn to use a debugger.

Running the Debugger

Xcode is set up so you don’t have to do much work to run the debugger. Every Xcode project you create has a Debug (older versions of Xcode call it Development instead of Debug) build configuration that is set for debugging. The Debug build configuration is the default configuration so all you have to do is choose Build > Build and Debug to open the debugger window and start debugging.

The debugger window has four areas. At the top is the toolbar, which has buttons for performing the most common debugging tasks. You can also find these debugging commands in Xcode’s Debug menu.

Below the toolbar on the left is the call stack viewer. At the top of the call stack is the function where your program current is. Below that is the function that called the current function. Below that is the function that called the second function and so on. The call stack viewer is the least interesting part of the debugging window for those of you who are new to debuggers.

Next to the call stack viewer is the variable viewer. The variable viewer lets you see the values of the current function’s local variables and arguments as well as any constant variables that are in the current function’s source code file.

At the bottom of the debugger window is the editor, which lets you see what line of code the program is currently at.

Setting Breakpoints

Launching the debugger initially doesn’t do anything because you haven’t told the debugger when to pause. Breakpoints tell the debugger to pause your program when it reaches a certain line of code. What you have to do is set breakpoints where you want your program to pause.

Click the gutter next to a line of source code in the editor window to set a breakpoint at that line of code. The gutter runs along the left edge of the window. When you set a breakpoint, a gray arrow appears next to the line of code. Dragging the arrow off the gutter removes the breakpoint.

Now when you run your program in the debugger, it will pause when it reaches any of the breakpoints you set.

Stepping Through Your Code

Stepping is one of the most important functions a debugger performs. It lets you walk through one line of code at a time and see the effects of executing that line of code. If you look at Xcode’s debugger window toolbar, you will see three buttons: Step Over, Step Into, and Step Out. If the current line of code does not call a function, the Step Over and Step Into buttons do the same thing. They execute the current line of code and move to the next line.

The Step Over and Step Into buttons perform different tasks when making a function call. Clicking the Step Over button tells the debugger to execute all the code in the function you’re calling and move to the line of code after the function call. It steps over the function you’re calling.

Clicking the Step Into button takes you inside the function you’re calling, which lets you step through the code inside the called function. It steps into the function you’re calling. When you step into a function, the Step Out button becomes relevant. Clicking the Step Out buttons takes you out of the called function and moves to the line of code after the function call. Clicking the Step Into and Step Out buttons is the equivalent of clicking the Step Over button.

Conclusion

For more information on Xcode’s debugger, read the Xcode’s User Guide, which you can open in Xcode by choosing Help > Xcode Help. There is an entire section on debugging.

Facebooktwittergoogle_plusredditmail

7 thoughts on “Introduction to Xcode’s Debugger

  1. Anonymous says:

    Thanks!

    Nice guide

  2. Anonymous says:

    This is very helpful!!

  3. Anonymous says:

    Hello,
    Thanks for the quick guide.
    When I debug a small c++ program in xcode 3, I can’t get the debugger to stop on my first breakpoint; it just goes passed it to the first cout statement. However, when I debug the same code in Visual C++ 2008 Express it stops on every breakpoint.
    Is this how xcode is intended to work? Or is it a bug in the debugger?
    Thanks Mark.

  4. Mark says:

    If you set a breakpoint on a line of code that doesn't do anything, such as a variable declaration, the debugger won't stop at the breakpoint. The debugger will stop at the next line of code that does something. I did a test on a small command-line C++ program. When I set a breakpoint on a variable declaration, the debugger stopped at the next line of code instead of the line where I set the breakpoint.

    If you set a breakpoint on a line of code that does something, such as a cout statement, and the debugger isn't stopping at breakpoints, make sure you have turned off code optimization. Code optimization can eliminate lines of code. The Optimization Level build setting is in the GCC Code Generation collection.

    If you turn off code optimization and the debugger is skipping your breakpoint, open Xcode's preferences window by choosing Xcode > Preferences. In the Debugging section, deselect the Load Symbols Lazily checkbox. Loading symbols lazily is a common cause of breakpoints being skipped.

  5. Mark Reid says:

    Thanks for this quick guide. It really helped me to understand what the debugger can do to help me out of bugs in my code. If only I knew this a while ago. 😀

  6. Nathaniel Palmer says:

    Very helpful. Thanks. Didn't realize that "loading symbols lazily" could cause so much trouble.

  7. Tony says:

    Another thing I love about the debugger that wasn't mentioned is that when the program is stopped at a breakpoint, and you are stepping thru the code, you can hover the cursor over variables to get an instant popup that shows their type and value. Much faster way to check values than scrolling thru the Variable list.

Leave a Reply

Your email address will not be published. Required fields are marked *