Debugging Applications

This chapter describes the Xcode debugging facilities.

Part of your debugging workflow may require to view or manipulate data your application writes in its file system. For example, you may need to edit the data the application has stored to recreate a particular condition you want to test. See “Managing Application Data” for details about manipulating your application’s data.

Debugging Facilities Overview

Xcode provides several debugging environments you can use to find and squash bugs in your code:

• The text editor. The text editor allows you to debug your code right in your code. It provides most of the debugging features you need. You can:

  • Add and set breakpoints

  • View your call stack per thread

  • View the value of variables by hovering the mouse pointer over them

  • Execute a single line of code

  • Step in to, out of, or over function or method calls

  

• The Debugger window. When you need to perform more focused debugging, the Debugger window provides all the debugging features the text editor provides using a traditional interface. This window provides lists that allow you to see your call stack and the variables in scope at a glance.

  

• The GDB console. A GDB console window is available for text-based debugging.

For more information about the Xcode debugging facilities, see Xcode Debugging Guide.

Viewing Console and Crash Logs

The iPhone OS frameworks, such as UIKit, produce log entries to the console to indicate, among other things, when an unexpected event occurs. You can produce console messages in your iPhone applications, too. One way to produce console logs is to use the NSLog function. In addition to the Xcode debugger, console logs may help you analyze your application’s logic and track down bugs.

When running your application on iPhone Simulator, you can access its console logs in Console application (located /Applications/Utilities). When you run the application on your development device, log entries from your application appear in the Xcode Organizer.

To view a device’s console output:

1. Open the Organizer window.

2. Select the device whose console log you want to view.

3. Click Console.

   

You can use the search field to filter log entries. You can also save the log to a file.

The Crash Logs pane in the Organizer contains information about application crashes. You may have to unplug your device and plug it in again to refresh the crash list.

Finding Memory Leaks

If you fix a leak and your program starts crashing, your code is probably trying to use an already-freed object or memory buffer. To learn more about memory leaks, see Finding Memory Leaks.

You can use the NSZombieEnabled facility to find the code that accesses freed objects. When you turn on NSZombieEnabled, your application logs accesses to deallocated memory, as shown here:

2008-10-03 18:10:39.933 HelloWorld[1026:20b] *** -[GSFont ascender]: message sent to deallocated instance 0x126550

To activate the NSZombieEnabled facility in your application:

1. Choose Project > Edit Active Executable to open the executable Info window.

2. Click Arguments.

3. Click the add (+) button in the “Variables to be set in the environment” section.

4. Enter NSZombieEnabled in the Name column and YES in the Value column.

5. Make sure that the checkmark for the NSZombieEnabled entry is selected.

For more information about configuring executable environments, see “Configuring Executable Environments” in Xcode Project Management Guide.

iPhone 3.1 SDK introduces the Leaks instrument, which you can use in the Instruments application to easily find memory leaks. For more information, see Instruments User Guide.