iOS development--&breakpoints, Lldb and Chisel in the test chapter

breakpoints, Lldb and chisel

Breakpoints

Breakpoint classification

Breakpoint is also classified, I am here in the article roughly according to the way used to divide

• Normal Breakpoint,
• Exception Breakpoint,
• OpenGL ES Error Breakpoint,
• Symbolic Breakpoint,
• Test Failure Breakpoint,
• Watchpoints.

You can use different types of breakpoint to solve the problem as a specific scenario.

Normal Breakpoint

Adding a normal breakpoint is not much to say, click on the right side of the source code. Alternatively, use the shortcut key: Command + \ To add and remove. These two ways to add the breakpoints above Xcode can be seen through the UI.

There are also the following two LLDB commands to add breakpoints directly at run time, but it is important to note that on the one hand you can not directly see the breakpoint through the UI, on the other hand, only exist in this run, the next time the emulator to start the new run, these breakpoints will not take effect.

For example, the "BR li" command to print all the breakpoint, you can see a total of 3 breakpoint, the first one is added via the Xcode UI, the next two are added by the following two commands:

"Breakpoint Set-f xxx.m-l XX" and "B xxx.m:xx".

Exception Breakpoint

You can add exception breakpoint through the UI in Xcode. Sometimes, such as the array out of bounds or set an empty object and other problems, will throw an exception, but this type of error is very difficult to locate, this time you can use exception breakpoint to debug, when the exception occurs, you can catch and stop the execution of the program. The exception in OC is an often overlooked place, but in fact the system framework is very widely used, most of this error message, the system framework will be thrown out in the form of exceptions, so use this breakpoint, we can greatly reduce the time to find the wrong.

For example, after we add the following exception breakpoint (the BT command is explained later in this article, the function of this command is to print the callback stack information when the breakpoint is triggered):

Like the following array of cross-border problems, we can easily locate the problem, no longer have no clue to find out:

When the breakpoint pauses execution, we can view the call stack information through the Xcode UI:

or view the call stack information printed by the BT command:

There are also errors like the following that can be easily located by this breakpoint:

, but this problem can be avoided by using Setvalue:forkey: instead.

OpenGL ES Error Breakpoint

In the middle, add a button to the lower part of Xcode's Breakpoint Navigator and select "Add OpenGL ES Error breakpoint". This breakpoint is primarily used to stop the program from running when OpenGL ES errors occur.

Symbolic Breakpoint

Add symbolic breakpoint through the UI of Xcode with exception breakpoint, the popup box is as follows:

Symbolic breakpoints when a particular function or method starts executing, pausing the execution of the program, adding breakpoints in this way, we do not need to know whether to add in the source file, or need to know the breakpoint is set in the first line of the file.

, the main setting is the content of symbol, which can be as follows:

• 1. A method name, which is used for all classes, such as Pathsmatchingextensions: Method name.
• 2. A method of a particular class. A method of a particular class. For example, [Skline Drawhandlesinview], or people::P erson::name ()
• 3. A function name. The function name. For example, _objc_msgforward such a C function.

Alternatively, you can add symbolic breakpoints by using the command line method. To add a breakpoint to the C function:

To add a breakpoint to the OC method:

Commonly used in this type of breakpoint, Objc_exception_throw can be used instead of exception breakpoint, there is a-[nsobject Doesnotrecognizeselector:] is also more commonly used, Used to detect failed method calls.

Test Failure Breakpoint

Add the same method as the UI via Xcode. This type of break point pauses the execution of the program when test assertion fails.

Watchpoints

Watuchpoints is a tool used to listen for changes in the value of a variable or change in memory address, triggering a pause in the debugger when a change occurs. For those states that do not know how to track accurately, this tool can be used to solve the problem. To set the Watchpoint, when the program runs to a stack frame containing the variable you want to watch, let debugger pause and this time the variable is in the scope of the current stack frame, this time the variable can be set Watchpoint.

You can set watchpoint in Xcode's GUI, keep the variables you want to watch in Xcode's Variables view, then right-click to set "Watch XXX". For example, to observe the title variable of self, click Watch "_button1clickcount".

Command line

Alternatively, you can set the Watchpoint:watch set variable _button1clickcount from the command line, and the detailed commands can be consulted: http://lldb.llvm.org/lldb-gdb.html, there are several commands to achieve the same effect.

The above is an observation of the variable, in fact we can observe any memory address, the command is as follows: Watchpoint set expression-0x123456, reference: http://stackoverflow.com/questions/ 21063995/watch-points-on-memory-address

It is important to note that Watchpoint is a sub-type, including the Read,write or Read_write type, which is very easy to understand whether the watchpoint is triggered when reading, writing, or reading or writing variables or memory. Read,write or Read_write follows the-w parameter to represent the type. In addition, the command line, Watchpoint also have some shorthand, set shorthand for S,watch shorthand for wa,variable abbreviated to V.

The following example is a few commands from the http://www.dreamingwish.com/article/lldb-usage-a.html Web site:

The first command is to listen to the memory address of the _ABC4 variable write changes, the second is to listen to _ABC4 variable read changes, the third is to listen to _ABC3 variable read_write changes.

It is important to note that the Watchpoint added via the Xcode GUI is the default type, the write type, and if you want to add watchpoint for read and write watch, you can only add it through the command-line tool.

With Watchpoint modify-c ' (xxx==xx), the watchpoint is not monitored until a value is modified.

Editing options

Breakpoint Condition

When we edit breakpoint through Xcode, we can see that both normal breakpoint and symbolic breakpoint have a "Condition" input option, which is easy to understand, These breakpoints will only work if you set the condition expression to Yes.

For example, the breakpoint in will stop running when the string is judged equal:

You can notice the use of Stringwithutf8stirng: method, the reason is that LLDB expression parser has a bug, incompatible with non-ASCII characters, need to deal with the line, or will error "an objective-c Constant string ' s string initializer is not an array ", reference: http://stackoverflow.com/questions/17192505/ Error-in-breakpoint-condition

A simpler example would be a simple comparison such as I = = 99, as long as the result of the expression is type bool.

Breakpoint Actions

You can see that there is basically an "Add Action" option in each of the breakpoint editing options above, and when breakpoint is triggered, the actions we set are executed first, and then we get control, That is, Xcode shows the UI that the program stopped executing. This action is well understood by the example, and we illustrate it by the exception above that Setobject:forkey:. The code is as follows:

Set Breakpoint:

As you can see, we've set up a total of 3 action. The first action, used to print exception details, usage reference: http://stackoverflow.com/questions/17238673/ Xcode-exception-breakpoint-doesnt-print-details-of-the-exception-being-thrown.

The second action, we use the shell command "say", let the computer voice, read a paragraph of text.

The third action, we use the "BT" command to print the call stack information

After the setup is complete, when the exception occurs, we will hear the English in the computer voice reading, and then in the log can see the following information, the first line is exception description information, the following is the call stack:

Continuing after Evaluation

Looking at Breakpoint's edit pop-up window, we can find a "automatically continue after evaluation actions" checkbox option. When we tick this checkbox, debugger executes all of the actions added in breakpoint and then proceeds to execute the program. For us, in addition to triggering a lot of command and executing for a long time, the program will quickly skip this breakpoint, so we may not even notice the existence of this breakpoint. Therefore, the function of this option is equivalent to the execution of the last action after the direct input continue command to continue execution.

With this powerful feature, we can modify our program directly through breakpoints. Stop execution on a line of code and use the "expression" command to modify the UI directly by modifying one of the program's variable settings, and then continue execution. Expression/call with this option, it will be very powerful, it is very convenient to implement a lot of very powerful features.

For example, we implement the following function to change the background color of the selectbackgroundview of the first cell of TableView to red:

The action's content is "expression [[cell Selectedbackgroundview] Setbackgroundcolor:[uicolor Redcolor]", where the expression is not to be cared for first, We'll talk later in the Lldb chapter, after the change, when we click on the cell, the cell's background turns red:

In this way, we can implement various debugging effects on the UI without modifying one line of code, just by modifying the breakpoint.

iOS development--&breakpoints, Lldb and Chisel in the test chapter