- Creating New Projects
- Building Hello World the Template Way
- Using the Simulator
- The Minimalist Hello World
- Converting Interface Builder Files to Their Objective-C Equivalents
- Using the Debugger
- Memory Management
- Recipe: Using Instruments to Detect Leaks
- Recipe: Using Instruments to Monitor Cached Object Allocations
- Analyzing Your Code
- Building for the iOS Device
- Detecting Simulator Builds with Compile-Time Checks
- Performing Runtime Compatibility Checks
- Pragma Marks
- Preparing for Distribution
- Over-the-Air Ad Hoc Distribution
- Submitting to the App Store
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Using the Debugger
Xcode’s integrated debugger provides a valuable tool for iPhone application development. This walkthrough shows you where the debugger is and provides a simple grounding for using it with your program. In these steps, you discover how to set breakpoints and use the debugger console to inspect program details. These steps assume you are working on the second, minimalist Hello World example just described and that the project window is open and the main.m file displayed.
Set a Breakpoint
Locate the helloController method in the main.m file of your Hello World project. Click in the leftmost Xcode window column, just to the left of the label assignment line. A blue breakpoint indicator appears (see Figure 3-10). The dark blue color means the breakpoint is active. Tap once to deactivate—the breakpoint turns light blue—and once more to reactivate.
){kind=link}
)
Figure 3-10. Blue breakpoint indicators appear in the gutter to the left of the editor area. You can reveal the debugger at the bottom of the workspace by clicking the Debugger disclosure button while running an application or by clicking the center of the three View buttons at the top-right of the workspace window at any time.
Remove breakpoints by dragging them offscreen or right-clicking them; add them by clicking in the column, next to any line of code. Once added, your breakpoints appear in the workspace’s Breakpoint Navigator (Command-6). You can delete breakpoints from the navigator (select, then press the Delete button) and can deactivate and reactivate them from there as well.
Open the Debugger
Compile the application (Product > Build, Command-B) and run it (Product > Run, Command-R). The simulator opens, displays a black screen, and then pauses. Execution automatically breaks when it hits the breakpoint. A green bar appears next to your breakpoint, with the text “Thread 1: Stopped at breakpoint 1.”
In Xcode, the debugging pane appears automatically as you run the application. You can reveal or hide it manually by clicking the middle of the three View buttons at the top-right of the workspace window; it looks like a rectangle with a dark bottom. When the debugger is shown, you can drag its jump bar (not the one at the top of the editor window, but the one at the top of the debugger) upward to provide more room for your output.
The debugger provides both a graphical front end for inspecting program objects as well as a text-based log area with an interactive debugger console. Xcode offers two command-line debuggers: gdb and lldb. The LLDB project (hosted at http://llvm.org) expands upon the standard GNU debugger (gdb) with improved memory efficiency and Clang compiler integration.
Select which debugger you wish to use by editing your project scheme, as shown in Figure 3-11. Select Edit Scheme from the pop-up at the left of your toolbar at the top of your workspace window just to the right of the Run and Stop buttons. (Make sure you’re selecting the Hello World part of the pop-up, not the iPhone or iPad simulator part.) Use the Info > Debugger pop-up to switch between GDB and LLDB. Click OK.
){kind=link}
)
Figure 3-11. The project scheme editor allows you to select which debugger you prefer to use.
Inspect the Label
Once stopped at the breakpoint, the interactive debugger and the debugger command line let you inspect objects in your program. Using lldb, you can look at the label by typing print-object label or, more simply po label at the command line. Use print or p to print non-objects, such as integer values.
(lldb) po label (UILabel *) $3 = 0x06a3ded0 <UILabel: 0x6a3ded0; frame = (0 0; 320 80); clipsToBounds = YES; userInteractionEnabled = NO; layer = <CALayer: 0x6a3df40>>
At this time, the label’s text has not yet been set and it has not yet been added to the view controller’s view. You can confirm that the label is not yet added to the view by looking at the view controller’s view’s subviews, currently an empty array, and the label’s superview, currently nil.
(lldb) po [[vc view] subviews] (id) $4 = 0x06811e20 <__NSArrayI 0x6811e20>( ) (lldb) po [label superview] (id) $5 = 0x00000000 <nil> (lldb)
You can also view the label directly using the inspector at the left side of the debugger. Locate label and click the disclosure triangle to the left of it to show the properties of the label object. The label’s _text field is set to <nil>.
The Step Into button appears to the left of the debugger jump bar. It looks like an arrow pointing down to a small black line. Click it once. The text assignment executes and the green arrow moves down by one line. The summary of the label.text updates. It should now say something like “Hello World (iPhone).” Confirm by inspecting the label from the command line by typing po label again. The label has updated its text instance variable to Hello World.
(lldb) po label (UILabel *) $12 = 0x06a3ded0 <UILabel: 0x6a3ded0; frame = (0 0; 320 80); text = 'Hello World'; clipsToBounds = YES; userInteractionEnabled = NO; layer = <CALayer: 0x6a3df40>>
If you want to get really crazy, you can override values directly by using p or print to make interpreted calls during the execution of your application. This call changes the label text from “Hello World” to “Bye World.” It does that by executing the items within the square brackets, casting the void return to an integer, and then printing the (meaningless) results.
(lldb) p (int)[label setText:@"Bye World"] (int) $13 = 117671936 (lldb) po label (UILabel *) $14 = 0x06a3ded0 <UILabel: 0x6a3ded0; frame = (0 0; 320 80); text = 'Bye World'; clipsToBounds = YES; userInteractionEnabled = NO; layer = <CALayer: 0x6a3df40>>
Set Another Breakpoint
You can set additional breakpoints during a debugging session. For example, add a second breakpoint just after the line that sets the text alignment to center, on the line that sets the background color. Just click in the gutter next to label.backgroundColor, or wherever you want to set the breakpoint.
Confirm that the current alignment is set to 0, the default value, by inspecting the label’s textLabelFlags—you will have to open the disclosure triangles in the column to the left of the lldb interface to see these label attributes. With the new breakpoint set, click the Resume button. It appears as a right-pointing triangle with a line to its left.
HelloWorld resumes execution until the next breakpoint, where it stops. The green arrow should now point to the backgroundColor line, and the explicit alignment flag updates from 0 to 1 as that code has now run, changing the value for that variable.
(lldb) p (int) [label textAlignment] (int) $19 = 1
You can further inspect items by selecting them in the left-hand debugging inspector, right-clicking, and choosing Print Description from the contextual pop-up menu. This sends the description method to the object and echoes its output to the console.
List your breakpoints by issuing the breakpoint list command. Lldb prints out a list of all active breakpoints.
(lldb) breakpoint list Current breakpoints: 1: file ='main.m', line = 26, locations = 1, resolved = 1 baton: 0x11b2dd380 1.1: where = Hello World`-[TestBedAppDelegate helloController] + 365 at main.m:26, address = 0x0000211d, resolved, hit count = 1 3: file ='main.m', line = 30, locations = 1, resolved = 1 baton: 0x12918d6c0 3.1: where = Hello World`-[TestBedAppDelegate helloController] + 912 at main.m:30, address = 0x00002340, resolved, hit count = 0
Backtraces
The bottom pane of the debugging window offers text-based debugger output that can mirror results from other panes. For example, open the Debug Navigator and view the application by thread, disclosing the trace details for Thread 1. This provides a trail of execution, showing which functions and methods were called, in which order to get you to the current point where your application is.
Next, type backtrace or bt at the text debugger prompt to view the same trace that was shown in that navigator. After stopping at the second breakpoint, the backtrace should show that you are near (for example, line 26 in the source from main.m). You will see this line number toward the beginning of the trace, with items further back in time appearing toward the end of the trace. This is the opposite of the view shown in the Debug Navigator, where more recent calls appear toward the top of the pane.
Console
This bottom text-based debugger is also known as the console. This pane is where your printf, NSLog, and CFShow messages are sent by default when running in standard debug mode or when you use the simulator. You can resize the console both by adjusting the jump bar up or down and also by dragging the resize bar between the left and right portions of the debugger. If you want, you can use the show/hide buttons at the top-right of the debugger. Three buttons let you hide the console, show both the console and the visual debugger, or show only the console. To the left of these three buttons is a Clear button. Click this to clear any existing console text.
To test console logging, add a NSLog(@"Hello World!"); line to your code; place it after adding the label as a window subview. Remove any existing breakpoints and then compile and run the application in the simulator. The log message appears in the Debug area’s console pane. The console keeps a running log of messages throughout each execution of your application. You can manually clear the log as needed while the application is running.
Add Simple Debug Tracing
If you’re not afraid of editing your project’s .pch file, you can add simple tracing for your debug builds. Edit the file to add the following macro definition:
#ifdef DEBUG
#define DebugLog(...) NSLog(@"%s (%d) %@", __PRETTY_FUNCTION__, __LINE__,
[NSString stringWithFormat:__VA_ARGS__])
#else
#define DebugLog(...)
#endif