Shulou(Shulou.com)06/02 Report--

Editor to share with you how to symbolize the iOS crash stack information. I hope you will get something after reading this article. Let's discuss it together.

Use and techniques for symbolizing iOS crashes:

I. scene

When we collect crash information for iOS, the crash stack we get is generally in the following form, all in hexadecimal memory address form:

It is difficult to see the actual meaning of such a format, it is impossible to locate the problem code, and it only makes sense to convert them into a readable form:

As shown above, we can see at a glance that the crash occurred on line 68 of the ViewController.m file, corresponding to the method rangeException. So how is such symbolization realized?

We know that when developers use Xcode to develop and debug App, once they encounter a crash problem, they can directly use Xcode's debugger to locate and analyze the crash stack. But if the App is released and the user's phone crashes, we can only locate the problem by analyzing the crash log recorded by the system. In this crash log file, we will point out the memory address of the function where App went wrong, the key problem, and there is only an address in the crash log, like 0x2312e92f. Doesn't this seem like a headache? what should we do?

Fortunately, the existence of dSYM files is an important way to help struggling programmers locate bug problems effectively. The function address in the crash stack can find the specific file name, function name and line number information with the help of the dSYM file. In fact, when you use Xcode's Organizer to view the crash log, you symbolize it based on the locally stored .dSYM file.

II. Xcode symbolization tool

Xcode itself also provides several tools to help developers symbolize function addresses.

1 、 symbolicatecrash

Symbolicatecrash is a script that symbolizes the stack address. The input parameters are Apple's official crash log and the local .dSYM file.

The execution is as follows:

Symbolicatecrash + crash log + .dSYM file corresponding to APP + > + output file

But there are great limitations in using symbolicatecrash tools.

(1) you can only analyze crash logs in official format, which need to be derived from specific devices. It is not very convenient to obtain and operate them.

(2) the result of symbolization has no specific line number information, and symbolization failure often occurs.

In fact, Xcode's Organizer has a built-in symbolicatecrash tool, so developers can see the symbolic crash stack log directly.

2 、 atos

More generally, developers can get the error stack information, and using the atos tool is to find the specific symbol information corresponding to the address. It is a tool that can convert addresses to function names (including line numbers)

The execution is as follows:

Atos-o executable-arch architecture-l loadAddress address

Description:

LoadAddress represents the dynamically loaded address of the function, corresponding to the address before the + sign in the crash address stack, that is, 0x00048000

Address represents the runtime address, which corresponds to the first address in the crash address stack, that is, 0x0004fbed. In fact, the address before and after the + sign in the crash address stack is the runtime address, that is, 0x00048000 + 31720 = 0x0004fbed

Execute the command to query the symbol of the address, and you can see the following results:

-[ViewController rangeException:] (in xx) (ViewController.m:68)

III. Principle of stack symbolization

So, how do we do this if we symbolize the stack ourselves? Here you need to deal with two kinds of symbols, including user symbols and system symbols.

1. Symbolization of user stack

The basis for symbolization comes from dSYM files, and dSYM files are also in Mach-o format. We can parse them step by step according to Mach-o format.

From the picture, we can roughly see that Mach-O can be divided into three parts.

(1) Header

(2) Segment

(3) section

As shown in the figure, header is followed by segment, followed by section, and a segment can contain multiple section.

We put the dSYM file into the visualization tool:

The dSYM file contains the symbol tables of armv7 and arm64 architectures. We only look at armv7 (the same as arm64). It offsets 64 and navigates directly to 64 (0x00000040). Here is the Mach Header information above.

Two places related to our symbol table are "LC_SYMTAB" and "LC_SEGMENT (_ _ DWARF)"-> "Section Header (_ _ debug_line)".

LC_SYMTAB information

Location address: offset 4096 + 64 (0x1040), get the function symbol information module "Symbols", and parse the function symbols, such as the memory address corresponding to the first function: "- [DKDLicenseAgreeementModel isAuthorize]": module address + 43856

"_ _ debug_line" module

This module contains code file line number information, which is parsed one by one according to the dwarf format.

First navigate to SEGMENT:LC_SEGMENT (_ _ DWARF), and then to Section:__debug_line

Its offset value: 4248608, 4248608 + 64 = 0x40D460, navigate to "Section (_ _ DWARF,__debug_line)"

This is the specific line number information, which is parsed according to the dwarf format.

The parsed results are as follows:

The first column is the starting memory address, the second column is the end memory address, and the third column is the corresponding function name, file name, line number information, so that we can easily restore any crash information.

There is nothing wrong with the Object-C symbols parsed above, but if they are C++ or Swift symbols, they still need special treatment.

Swift symbol:

The Swift function is name mangling, so the original symbols parsed from dSYM are not very intuitive.

We use "swift-demangle" to restore: swift-demangle-simplified originName, and the result is as follows:

C++ symbol:

The C++ function is also name mangling, so the original symbol parsed from dSYM is as follows:

We use "c++filt" to restore: c++filt originName, and the result is as follows:

2. Symbolization of system stack

Unresolved form:

After parsing:

Apple does not provide the function of downloading the symbol table of the system library. We can get it through the real machine.

When the developer is connected to the MAC, the symbols of the model will be copied to the computer first.

What "Processing symbol files" does is copy the system symbol to the computer and copy the address:

~ / Library/Developer/Xcode/iOS DeviceSupport

But there is a drawback, that is, your real machine will not have enough iOS versions, including all versions, so the system symbol will be missing, another way is to download a variety of iOS firmware and parse it from the firmware.

After reading this article, I believe you have a certain understanding of "how to symbolize the iOS crash stack information". If you want to know more about it, welcome to follow the industry information channel. Thank you for your reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.