Lập trình Wrox Professional Xcode 3 cho Mac OS part 61 ppsx

460 ❘ CHAPTER 18 DEBUGGING Showing the Type column is probably the fi rst thing I do after opening the debugger window for the fi rst time. Alternatively, you can also Right/Control - click any variable and choose Show/Hide Type Column from the pop - up menu. Sadly, Xcode doesn ’ t preserve this setting between Xcode sessions. There ’ s a lot more to examining data in the debugger. This brief overview should give you some idea of what you ’ re looking at while you progress to the more practical topic of controlling the debugger and setting breakpoints. Until you can stop your application, there ’ s no data to examine. CONTROLLING THE DEBUGGER One of the most elementary, and often most effective, methods of debugging an application is simply to stop it and examine its state. Look at the value of local variables and objects, and see what functions have been called and in what order. You may then want to step through the code one line at a time to witness its order of execution. This, rather passive, method of debugging is often all that ’ s required to determine what your code is doing wrong or unexpectedly. You control this kind of immediate and interactive debugging through a set of debugging commands. None of these commands (except the Pause command) is available until the debugger has suspended your application. This happens when the execution of your program encounters a breakpoint, some exceptional event, or when you use the Pause command. The most predictable method is to set a breakpoint. It ’ s possible to stop your program using the Debug ➪ Pause command, but it ’ s rarely that useful. Pause stops your program wherever it is at that moment — usually in some framework or kernel call. Breakpoints can do many sophisticated things, and you can set them in a variety of ways, all of which is covered later in the “ Breakpoints ” section. For now, all you need to do is set and enable simple breakpoints by clicking in the editor pane gutter of any source fi le. A breakpoint appears as a blue marker that indicates the position of the breakpoint in the source code. Clicking an existing breakpoint toggles its state between enabled (blue) and disabled (grey). Only enabled breakpoints interrupt program execution. To delete a breakpoint, drag the breakpoint out of the gutter or use the Right/Control - click menu to select the Remove Breakpoint command. After the execution of your program has been suspended, a set of execution control commands becomes available. These are listed in the following table: COMMAND SHORTCUT DESCRIPTION Continue Option+Command+P Resumes execution of your program. Your program will run until it encounters another breakpoint or terminates. Pause Option+Command+P Immediately suspends execution of your program. This is the only command that will stop your program without setting a breakpoint. c18.indd 460c18.indd 460 1/22/10 12:54:57 PM1/22/10 12:54:57 PM Download at getcoolebook.com COMMAND SHORTCUT DESCRIPTION Step Into Shift+Command+I Executes one line of source code. If the line contains a call to another function, execution is stopped again at the beginning of that function, which is what gives this command its name — you are stepping into the function being called. If the source line does not call another function, this command is equivalent to Step Over. Step Over Shift+Command+O Executes one line of source code and stops before executing the line that follows. If the line contains calls to other functions, those functions are allowed to execute in their entirety. Step Out Shift+Command+T Resumes execution until the current function returns to its caller. Step Into Instruction Option+Shift+Command+I Equivalent to Step Into, but steps through a single machine instruction rather than a full line of source code, that might translate into dozens of machine instructions. Step Over Instruction Option+Shift+Command+O Equivalent to Step Over, but steps over only a single machine instruction. ( continue to here ) Option+click in gutter Sets a temporary breakpoint and starts the program running. Sync With Debugger Returns the debugger window ’ s view to showing the current thread, current stack frame, current function, and current PC indicator where the debugger last suspended your process. Stop Shift+Command+Return Forcibly terminates your program ’ s process. Pause and Continue The Pause and Continue commands are immediate and self - explanatory. They share the same menu item, toolbar button, and keyboard shortcut. The Pause command is active whenever the process is executing, and the Continue command is active whenever it is suspended. Generally, the Pause command isn ’ t very useful for working GUI applications, because it tends to suspend the application in a run loop. You will probably fi nd it most edifying when your application is stuck in an endless, or seemingly endless, loop. It can also be helpful to suspend your application while you think about your next move or contemplate where to set a breakpoint. You don ’ t have to stop the program to set a breakpoint, but you don ’ t necessarily want your application running amuck while you decide where it should go. Controlling the Debugger ❘ 461 c18.indd 461c18.indd 461 1/22/10 12:55:03 PM1/22/10 12:55:03 PM Download at getcoolebook.com 462 ❘ CHAPTER 18 DEBUGGING Step Over and Into Step Over and Step Into are the two most commonly used debugger control commands. Step Over lets you walk through the logic of a single function, ignoring the details of other functions that it might call. Step Into traces the execution of the program one step at a time, regardless of where that leads. Step Into, Step Over, Continue to Here, and many other debugger commands work by setting temporary breakpoints. A temporary breakpoint is one created by the debugger for some ephemeral purpose, which it then deletes as soon as it ’ s reached. For example, the Step Into command works by setting a temporary breakpoint at the beginning of the function that you want to step into. It then lets the process execute. Most of the time this works as expected. You may, however, encounter unexpected behavior if the code encounters another breakpoint fi rst (possibly in another thread) or if there ’ s an exceptional event; the debugger will stop there instead. A different situation arises if a function exits abnormally (via a longjmp , by throwing an exception, or by terminating a thread) — the program may never execute the code wherein the temporary breakpoint was set. In this situation, the program avoids the breakpoint and continues running indefi nitely. The Step Over command is intelligent about recursive functions. Stepping over a function that calls itself does not stop until all nested iterations of the function have executed and returned, even if that entails executing the same code position that you are stepping over. If your editor pane is in disassembly view, Step Into and Step Over behave exactly the same way, but they each execute a single machine instruction — instead of the group of instructions generated by the single line of source code. If the source line contains multiple calls, the Step Into command steps into the fi rst function called. This is signifi cant if a function passes parameters that are obtained by calling other functions. The example in Listing 18 - 2 illustrates this. If the debugger fi rst stopped at this line and you issued the Step Into command, the debugger would step into getDefaultMode() , not setMode() . That ’ s because the getDefaultMode function is called fi rst to obtain the value of setMode ’ s single argument. LISTING 18 - 2: Nested function calls setMode(getDefaultMode()); // reset the mode c18.indd 462c18.indd 462 1/22/10 12:55:05 PM1/22/10 12:55:05 PM Download at getcoolebook.com After you return from getDefaultMode (see the Step Out command), the debugger again returns to this line of source code, but the CPU ’ s program counter is now poised at the call to setMode . This time the Step Into command steps into the setMode function. This is the situation where the hover step controls are exceptionally useful. Hover your cursor over the function or method name you want to step into and click its step into button. Xcode will step into that specifi c function, allowing any prerequisite functions to execute without interruption. Step Into only steps into functions that have debug information and have local source fi les associated with them. You cannot step into library functions, framework APIs, or kernel code that was not compiled with full debug information. Attempting to step into such a function is treated like a Step Over. Stepping Out Step Out is convenient for letting the current function complete its execution and return again to the point where it was called. It ’ s common to step into a function simply to examine the values of its arguments. After you are satisfi ed the function is behaving correctly, you can then use Step Out to let the function fi nish and return to where it was called. The same issues about exceptional exits that apply to Step Over also apply here. Stepping Over and Into Single Instructions The special Step Into Instruction and Step Over Instruction perform the same actions as the Step Into and Step Over, but each only executes a single machine instruction. These functions work in either source or disassembly view, but are most useful when you ’ re viewing both the source and disassembly of your program ’ s code where the meaning of Step Into and Step Over becomes ambiguous. Step Into Instruction is also away around the Step Into command ’ s self - imposed limitation of never stepping into a function that doesn ’ t have source information (like a library function). If the function being called has no source code available, Step Into Instruction still steps into it, automatically switching to a disassembly - only view, as required. Continue to Here The continue to here command doesn ’ t appear in the menu and has no keyboard shortcut. A continue to here button appears when you hover over an executable line number in the gutter. You can also use this, much quicker, shortcut: Option+click a line number in the gutter The continue to here action creates a temporary breakpoint and starts your application running, just as if you had set a regular breakpoint and issued the Continue command. A breakpoint indicator is not visible in the gutter or anywhere else in Xcode, and the breakpoint is deleted as soon as it is ➤ Controlling the Debugger ❘ 463 c18.indd 463c18.indd 463 1/22/10 12:55:15 PM1/22/10 12:55:15 PM Download at getcoolebook.com 464 ❘ CHAPTER 18 DEBUGGING hit. This makes it extremely easy to skip through blocks of code or around loops by simply clicking where you want to stop next. The same caveats about temporary breakpoints mentioned earlier apply here. THE MINI - DEBUGGER The mini - debugger is a compact debugger control window that ’ s intended to be used in situations where switching between your application and Xcode is awkward or impossible. This is particularly true of applications that present full - screen multimedia, games, animation, screen savers, and similar environments. You open the mini - debugger with the Run ➪ Mini - Debugger (Control+Command+Home) command. It opens a small fl oating window, shown on the left in Figure 18 - 17. The mini - debugger window fl oats above all other window layers, including the menubar, so it stays visible regardless of what application you switch to or what other windows are displayed. FIGURE 18-17 While the application is running, the mini - debugger window has four buttons: Stop Pause (De)activate Breakpoints Xcode The stop, pause, and toggle breakpoints button each perform their respective action. The Xcode button simply returns you to the Xcode application — often handy in applications where all of the Xcode windows and the menubar are obscured. Whenever the application is paused, the mini - debugger window expands to show a small editor pane, as shown on the right in Figure 18 - 17. The pane has all of the in - editor debugger controls described in the “ In - Editor Debugging ” section. ➤ ➤ ➤ ➤ c18.indd 464c18.indd 464 1/22/10 12:55:21 PM1/22/10 12:55:21 PM Download at getcoolebook.com If you like the mini - debugger, you ’ ll probably want to set the On Start Open Mini Debugger setting in the debugging preferences pane. BREAKPOINTS Breakpoints are locations in your program where you want the debugger to take control. Formally, a breakpoint is set at a particular address in memory. When the CPU ’ s program counter matches the address of a breakpoint — that is to say at the instant before the instruction at that breakpoint ’ s address is to be executed — the CPU stops executing your program and passes control to the debugger. So far you ’ ve created only basic breakpoints. The default action of a breakpoint is to halt the execution of your program, hand over control to the debugger, and wait for instructions, but breakpoints are capable of much more. Before getting into more advanced techniques for defi ning breakpoints, here ’ s a quick review of the methods for creating a basic breakpoint — one that simply stops the program when encountered: Click in the gutter of a source fi le. Right/Control - click in the gutter of a source fi le and choose the Add Breakpoint command. Choose the Run ➪ Manage Breakpoints ➪ Add Breakpoint At Current Line (Command+\) command when the active text cursor is in a source fi le. Use any of the debugger commands to create a temporary breakpoint and start the program running. When you ’ re setting breakpoints graphically, Xcode allows you to set a breakpoint on just about any line of the source fi le. A lot of times this doesn ’ t make any sense, but Xcode can ’ t tell that. When you set a breakpoint in a source fi le, you ’ re actually setting the breakpoint at the fi rst executable instruction produced by the source fi le at, or following, the line you clicked. Figure 18 - 18 shows three breakpoints set in a source fi le. All three of these breakpoints point to the same address location. The fi rst one is set on a declaration statement that produces no code, and the second one is set on a completely blank line. Only the source code on line 30 produces any executable code in the application. Ultimately, you could set a breakpoint on line 28, 29, or 30 with the same results. The breakpoint is set at the instruction that implements the switch statement. ➤ ➤ ➤ ➤ FIGURE 18-18 Breakpoints ❘ 465 c18.indd 465c18.indd 465 1/22/10 12:55:22 PM1/22/10 12:55:22 PM Download at getcoolebook.com . ❘ 461 c18.indd 461c18.indd 461 1/22/10 12:55: 03 PM1/22/10 12:55: 03 PM Download at getcoolebook.com 462 ❘ CHAPTER 18 DEBUGGING Step Over and Into Step Over and Step Into are the two most commonly. also Right/Control - click any variable and choose Show/Hide Type Column from the pop - up menu. Sadly, Xcode doesn ’ t preserve this setting between Xcode sessions. There ’ s a lot more to examining. visible in the gutter or anywhere else in Xcode, and the breakpoint is deleted as soon as it is ➤ Controlling the Debugger ❘ 4 63 c18.indd 463c18.indd 4 63 1/22/10 12:55:15 PM1/22/10 12:55:15 PM Download