Analysis of the symbol of iOS crash stack information

in recent times, programs often crash during iOS development and debugging, and after they're online. Simple crash It's okay to say that complex crashes need to be analyzed by parsing the crash file, parsing the crash file is more common in iOS development. However, in the process of communication with the developers, the cloud catcher found that everyone on the iOS application symbol table is not very clear.

650) this.width=650; "alt=" u=3993536932,2484420707&fm=21&gp=0 "src=" http:// Apk-pack-public-test.nos.netease.com/61cf416b7bf7400a9f38427a6300d70c.jpg?imageview "style=" border:0px;height : 321px;width:600px; "/>

There are many symbolic blogs about parsing crash stack information on the web, but most of the quality is uneven, or some details are not noticed. Summarize the use and tricks of the iOS crash symbol today:

A. Scene

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

        650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/a99cf3c7b55d4459933b879085c4fd07.png? ImageView "style=" border:0px;height:231px;width:600px; "alt=" A99cf3c7b55d4459933b879085c4fd07.png?ima "/>

        Such formats it's hard to see what the actual meaning is, and we can't locate the problem code, only it makes sense to convert it into a readable form:

         650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/0eb387a27ad743df9c75d8361f295d06.png? ImageView "style=" border:0px;height:256px;width:600px; "alt=" 0eb387a27ad743df9c75d8361f295d06.png?ima "/>

        as shown above, we can see at a glance that this crash occurred in line 68 of the Viewcontroller.m file, and the corresponding method is rangeexception. So how is this symbolic to be realized?

We know that when developers use Xcode to develop and debug apps, developers can locate the crash stack directly using Xcode's debugger when they encounter a crash problem. But if the app is released, the user's phone crashes, we can only analyze the system recorded crash log to locate the problem, in this crash log file, will indicate the app error function memory address, the key problem, crash log only address, similar to 0x2312e92f this, This does not seem to be quite a headache, how to do?

Fortunately there is the existence of dsym files, it is to help the hard-pressed yards farmers effectively locate the problem of the important way. The function address in the crash stack can use the dSYM file to find the specific file name, function name, and line number information. In fact, when you use Xcode's organizer to view the crash log, it is symbolized by the locally stored. dsym file.

two. Xcode symbology Tool

Xcode itself also provides several tools to help developers perform symbolic operations of function addresses

       1, Symbolicatecrash

< Span style= "Font-family:helvetica, ' Helvetica neue, Microsoft ya Black ', ' Microsoft Yahei ', ' Wenquanyi micro hei '; >       symbolicatecrash is a script that symbolized the stack address, the input parameter is the official Apple format crash log and the local. dsym file,
        EXECUTE as follows:
       symbolicatecrash + crash log + app-corresponding. dsym file + > + output to file,
  &NBSP ;     There are a lot of limitations with the Symbolicatecrash tool
        (1) can only analyze the official format of the crash log, need to export from specific devices, access and operation is not very convenient
        (2) The result of Symbolization is also the absence of specific line number information, and often there is the case of symbolic failure.
        In fact, Xcode's organizer has built-in Symbolicatecrash tools, so developers can see the symbolic crash stack log directly.

      2. Atos

More generally, developers can get the wrong stack of information, while using the Atos tool is to find the specific symbolic information corresponding to the address. It is a tool that converts addresses into function names (including line numbers).
This is done in the following ways:
Atos-o Executable-arch architecture-l loadaddress Address
Description
The loadaddress represents the dynamic load address of the function, corresponding to the address in front of the + sign in the crash address stack, which is 0x00048000
Address represents the run-time address, the first address in the stack corresponding to the crash address, i.e., 0x0004fbed, and in fact, the add-on addresses before and after the + sign in the crash address stack are run-time addresses, that is, 0x00048000+ 31720= 0x0004fbed
To execute the command query address symbol, you can see the following results:
-[viewcontroller Rangeexception:] (in XX) (viewcontroller.m:68)

three. The principle of stack symbolization

So, what if we were to symbolize the stack ourselves? There are two symbols to be processed, including user symbols and system symbols.

1. Symbolizing the user stack

       Symbolized by the basis from the dSYM file, dSYM file is also mach-o format, we follow the Mach-o format step-by-step analysis can be.

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/2e28286536924b1f9ff70418ebee0d7b.png? ImageView "style=" border:0px;height:648px;width:600px; "alt=" 2e28286536924b1f9ff70418ebee0d7b.png?ima "/>

From the figure we can probably see that mach-o can be divided into 3 parts
(1) Header
(2) Segment
(3) Section
, the header is followed by a segment, followed by section, and a segment can contain multiple sections.
We put the dsym file into a visualizer:

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/6ff1eacfd12345a78e6fd068cb31ab41.png? ImageView "style=" border:0px;height:210px;width:800px; "alt=" 6ff1eacfd12345a78e6fd068cb31ab41.png?ima "/>

The dSYM file contains symbol tables for the ARMV7 and arm64 two architectures, and we only look at ARMv7 (arm64), which is offset by 64 and is directly positioned to (0x00000040), which is the Mach header information above

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/6b2715714f6a4240844271b0f8282f12.jpg? ImageView "style=" border:0px;height:132px;width:800px; "alt=" 6b2715714f6a4240844271b0f8282f12.jpg?ima "/>

Two places related to our symbol table, one is "Lc_symtab", the other is "lc_segment (__dwarf)", "section Header (__debug_line)".

Lc_symtabInformation

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/2b9148abc6a84567af7466aedaa1e888.jpg? ImageView "style=" border:0px;height:218px;width:800px; "alt=" 2b9148abc6a84567af7466aedaa1e888.jpg?ima "/>

Positioning address: Offset 4096 + 0x1040, get the function symbol Information module "Symbols", the function symbol parsing out, such as the first function: "-[dkdlicenseagreeementmodel isauthorize]" corresponding memory address: Module Address +43856

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/0fb9c84be0844f4db15c65bde8353c61.jpg? ImageView "style=" border:0px;height:293px;width:800px; "alt=" 0fb9c84be0844f4db15c65bde8353c61.jpg?ima "/>

"__debug_line" module

This module contains code file line number information, according to dwarf format to a parse
First locate the Segment:lc_segment (__DWARF) and then navigate to the Section:__debug_line

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/0bd76bf2ac8e4f339589e29dffe9263e.jpg? ImageView "style=" border:0px;height:398px;width:800px; "alt=" 0bd76bf2ac8e4f339589e29dffe9263e.jpg?ima "/>

Its offset value: 4248608, 4248608+ = 0x40d460, navigate to section (__dwarf,__debug_line)
This is the specific line number information, according to the dwarf format to parse

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/2c21118bd0394c51ab9f539d0766e578.jpg? ImageView "style=" border:0px;height:421px;width:800px; "alt=" 2c21118bd0394c51ab9f539d0766e578.jpg?ima "/>

The results of the analysis are as follows:

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/33303485e1594c0997f9eb3f7cc12e90.jpg? ImageView "style=" border:0px;height:453px;width:600px; "alt=" 33303485e1594c0997f9eb3f7cc12e90.jpg?ima "/>

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

The object-c symbol above is not a problem, but if it's a C + + or Swift symbol, it needs special handling.

Swift symbol:

The SWIFT function will name the mangling, so the original symbol parsed from the dsym is not intuitive.

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/e84b1db642dd4bf28e92774de4f02a3d.jpg? ImageView "style=" border:0px;height:368px;width:800px; "alt=" E84b1db642dd4bf28e92774de4f02a3d.jpg?ima "/>

We use "Swift-demangle" to restore: swift-demangle–simplified Originname, the results are as follows:

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/e8e389ac3a7948bbbbab90309bccfd75.jpg? ImageView "style=" border:0px;height:427px;width:800px; "alt=" E8e389ac3a7948bbbbab90309bccfd75.jpg?ima "/>

C + + symbols:

C + + functions also name mangling, so the original symbols parsed from dSYM are as follows:

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/61cbb283c3d94f4ea6659ab45577e6cf.jpg? ImageView "style=" border:0px;height:354px;width:600px; "alt=" 61cbb283c3d94f4ea6659ab45577e6cf.jpg?ima "/>

We use "c++filt" to restore: C++filt Originname, the results are as follows:

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/7fbfc4f12cb84fa8a986482b9c8847ed.png? ImageView "style=" border:0px;height:361px;width:600px; "alt=" 7fbfc4f12cb84fa8a986482b9c8847ed.png?ima "/>

        2, symbology of the system stack

        Unresolved form:
650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/0669a7e0cd874950a08eeca0d2fa96d0.png? ImageView "style=" border:0px;height:244px;width:400px; "alt=" 0669a7e0cd874950a08eeca0d2fa96d0.png?ima "/>

After parsing:
650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/7f568f9fc2324b26a04511c74f29ab8f.png? ImageView "style=" border:0px;height:187px;width:400px; "alt=" 7f568f9fc2324b26a04511c74f29ab8f.png?ima "/>

Apple does not provide the download function of the System library symbol table, we can use the real machine to obtain
When the development machine is connected to the Mac, the symbol of the model is copied to the computer first.

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/bca34c6f4e5d42548ec03d6a46f0c298.png? ImageView "style=" border:0px;height:66px;width:800px; "alt=" Bca34c6f4e5d42548ec03d6a46f0c298.png?ima "/>

"Processing symbol files" Do is to copy the system symbols to the computer, copy the address:
~/library/developer/xcode/ios Devicesupport

650) this.width=650; "Src=" Http://apk-pack-public-test.nos.netease.com/ebc8470bcaa94502a78e1827432d0783.png? ImageView "style=" border:0px;height:297px;width:600px; "alt=" Ebc8470bcaa94502a78e1827432d0783.png?ima "/>

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

Four. Conclusion

In the actual project development, the analysis location of the crash problem is not in this way, because it relies on the system record of the crash log or error stack, in the Local development debugging phase, there is no problem.
If there is a crash in the published online version, the developer is not able to get the wrong stack instantly and accurately. In general, developers are access to third-party crash monitoring services (such as NetEase cloud capture), to achieve the online version of the crash issue of record and tracking.

Analysis of the symbol of iOS crash stack information