[Sink] iOS Advanced debug Rollup

1. The abbreviation of Po:print object, which represents the text description of the display objects, and prints nil if the object does not exist.

Simply print an object we won't talk about it, let's talk about special application scenarios!

Scenario: You want to know which sub-views a view contains. Of course you can cycle through the sub-view, but only one command is needed to resolve it.

Output view hierarchy (this is a hidden command):p o [[self view] recursivedescription]

There is also a common debugging scenario, such as you want to print a model. The result of your direct use of the NSLog or PO object is the model address, which is not what we want. What to do? Is there a way out?

The answer is yes. You can rewrite the description method inside the model. However, if the model has a lot of attributes, it doesn't work. You cannot say that the concatenation property is returned in the description method. This is not only cumbersome, but also very poor readability. Here, we can use runtime to dynamically get properties and return. But I do not recommend you to rewrite the description method, I recommend you rewrite the Debugdescription method, because the Debugdescription method and the description method effect, The difference is that the Debugdescription method is called when you use the PO command, and the description method is actually called.

2, P: can be used to print the basic data type.

3. Call: Execute a section of code

Call NSLog (@ "%@", @ "Yang")

4, Expr: Dynamic execution of the specified expression

Expr i = 101

Output: (int) $101

5. BT: Print the current thread stack information

If you want to print the thread stack information, use: BT all.

6, Image: Often used to find the stack address corresponding code location:

As an example:

Application scenario (array out of bounds) analog code:

Nsarray *array = @[@ "Yang" @ "she", @ "Bing"];

NSLog (@ "%@", array[3]);

The error message is as follows:

Terminating app due to uncaught exception ' nsrangeexception ', Reason: ' * * *-[__nsarrayi Objectatindex:]: Index 3 Beyon D bounds [0.. 2] '

First throw Call stack:

(

0 corefoundation 0x000000010579734b __exceptionpreprocess + 171

1 LIBOBJC. A.dylib 0x00000001051f821e Objc_exception_throw + 48

2 corefoundation 0x00000001056d1eeb-[__nsarrayi Objectatindex:] + 155

3 Bgmultimediademo 0x0000000104c25550-[viewcontroller Viewdidload] + 192

4 UIKit 0x0000000105d5c06d-[uiviewcontroller loadviewifrequired] + 1258

......

......

......

Bgmultimediademo 0X0000000104C25ADF main + 111

Libdyld.dylib 0x000000010857268d start + 1

??? 0x0000000000000001 0x0 + 1

)

Libc++abi.dylib:terminating with uncaught exception of type NSException

If we suspect that the wrong address is 0x0000000104c25550, then we can use the following command to find out where the error code is:

Image lookup--address 0x0000000104c25550 abbreviation: im lookup-a 0x0000000104c25550

After executing the command, the output is as follows:

ADDRESS:BGMULTIMEDIADEMO[0X0000000100001550] (Bgmultimediademo.__text.__text + 192)

Summary:bgmultimediademo '-[viewcontroller Viewdidload] + 192 at viewcontroller.m:30

As you can see from the output above, the error location should be 30 lines in the viewcontroller.m file. Isn't it super easy to use? Anyway, I think it works.

Third, Xcode debugging skills: Breakpoints (breakpoint)

Breakpoint, one of the programmer debug Essentials.

1. Conditional breakpoint

After you hit the breakpoint, edit the breakpoint and set the appropriate filter criteria. Here's a quick introduction to the conditional settings:

• Condition: Returns a Boolean value that, when the Boolean value is a true trigger breakpoint, normally we can write an expression.

• Ignore: Ignores the first n breakpoints, and then triggers the breakpoint to n+1 times.

• Action: Breakpoint trigger event, divided into six kinds:

1. AppleScript: Executes the script.

2. Capture GPU frame: used for OpenGL ES debugging, capturing the current drawing frame at the breakpoint at the GPU.

3. Debugger command: Matches the input lldb Debug command in the console.

4. Log message: Output custom format information to the console.

5. Shell command: Receive the command file and the corresponding parameter list, the shell command is executed asynchronously, only check "wait until done" will wait for the shell to finish executing debugging.

6. Sound: Sounds are played when a breakpoint is triggered.

These functions can be tried in the process of debugging the program, to be honest, I use the settings condition more.

Options (automatically continue after evaluating actions option): When selected, indicates that the breakpoint does not terminate the run of the program.

2. Abnormal Breakpoint

An exception breakpoint can quickly locate an exception that does not meet a particular condition, such as a common array out-of-bounds, which makes it difficult to navigate to the wrong location with exception information. At this point, an abnormal breakpoint can work.

To add an exception breakpoint:

To edit an exception breakpoint:

Exception: You can choose to throw exception object types: OC or C + +.

Break: The source of the thrown exception received by the Select breakpoint is the throw or catch statement.

3. Symbol Breakpoint

Symbolic breakpoints are created in the same way as an exception breakpoint, and you can specify a method to break execution in a symbolic breakpoint:

For example, in a common scenario, I want it to execute to the Viewwillappear method in the Viewcontroller class to break execution:

Symbol:[viewcontroller Viewwillappear:] That is, [class name Method name] can be executed into the specified method of the specified class to start the breakpoint. If only viewwillappear: that is, the method name, it executes to the viewwillappear in the class: The breakpoint is started in the method.

Four, Xcode debugging skills: exc_bad_access

1. Turn on Zombie objects

Turning on Zombie mode causes memory to rise, because objects that have been freed (reference count 0) are replaced by zombie objects and are not really released. This time again to send a message to the zombie object, will throw an exception, and print out the exception information, you can easily find the error code location, the end of Zombies will be released. Its main function is to detect wild pointer calls.

How to use:

"Edit Scheme ...", "Run", "diagnostics", "Zombie Objects"

Open the "Edit Scheme ..." window:

To turn on Zombie mode:

Note: The zombie mode can no longer be used on a real machine and can only be used on the emulator.

2. Address Sanitizer (disinfectant)

The addition of the Addresssanitizer tool after Xcode7 provides the convenience of debugging exc_bad_access errors. When the program creates a variable to allocate a piece of memory, the memory behind this memory is also frozen, identified as poisoned memory. When the program accesses the poisoned memory (access is out of bounds), it immediately interrupts the program, throws an exception, and prints the exception information. You can resolve the error based on the location of the interrupt and the log information of the output. Of course, if the variable has been freed, the memory it consumes will also be identified as poisoned memory, and this time access to the memory space will also throw an exception.

How to use:

"Edit Scheme ...", "Run", "diagnostics", "Zombie Objects"

After the Addresssanitizer is turned on, the program will automatically terminal and throw an exception if it encounters a exc_bad_access error during debugging.

[Sink] iOS Advanced debug Rollup