• iOS Crash 流程化3：Crash 產(chǎn)生和符號化的原理
  • 異常類型
    • Mach異常
    • Unix信號
  • 異常的產(chǎn)生
  • 線程回溯
    • 符號化回溯線程
      • 符號在二進(jìn)制中的偏移量
      • atos
  • 符號化內(nèi)幕
    • 小小結(jié)
  • 線程的狀態(tài)寄存器
  • Binary Images
  • 小結(jié)

iOS 的異常類型(Exception Type)由兩部分構(gòu)成：Mach異常、Unix信號異常。

異常類型

Mach異常

蘋果系統(tǒng)有一個微內(nèi)核，叫做XNU，它的源碼可以在opensource上下載到。Mach是XNU的核心，因而，Mach異常就指Mach內(nèi)核異常。Mach包含三部分內(nèi)容：thread，task，host。后續(xù)的章節(jié)中很多地方都會用到Mach。不妨移步到Mach IPC Interface，了解下Mach暴露給用戶的API。

Mach暴露給了用戶部分API，允許用戶和內(nèi)核交互。用戶態(tài)的開發(fā)者可以通過Mach API設(shè)置thread、task、host的異常端口，來捕獲Mach異常，抓取Crash事件。

Mach異常包括：

#define EXC_BAD_ACCESS        1    /* Could not access memory */
    /* Code contains kern_return_t describing error. */
    /* Subcode contains bad memory address. */

#define EXC_BAD_INSTRUCTION    2    /* Instruction failed */
    /* Illegal or undefined instruction or operand */

#define EXC_ARITHMETIC        3    /* Arithmetic exception */
    /* Exact nature of exception is in code field */

#define EXC_EMULATION        4    /* Emulation instruction */
    /* Emulation support instruction encountered */
    /* Details in code and subcode fields    */

#define EXC_SOFTWARE        5    /* Software generated exception */
    /* Exact exception is in code field. */
    /* Codes 0 - 0xFFFF reserved to hardware */
    /* Codes 0x10000 - 0x1FFFF reserved for OS emulation (Unix) */

#define EXC_BREAKPOINT        6    /* Trace, breakpoint, etc. */
    /* Details in code field. */

#define EXC_SYSCALL        7    /* System calls. */

#define EXC_MACH_SYSCALL    8    /* Mach system calls. */

#define EXC_RPC_ALERT        9    /* RPC alert */

#define EXC_CRASH        10    /* Abnormal process exit */

#define EXC_RESOURCE        11    /* Hit resource consumption limit */

Unix信號

信號是通知進(jìn)程已發(fā)生某種情況的軟中斷技術(shù)。例如：某個進(jìn)程執(zhí)行了除法操作，其除數(shù)為0，則將名為SIGFPE（浮點(diǎn)異常）的信號發(fā)送給該進(jìn)程。

異常的產(chǎn)生

那么，怎么會有兩種異常信息呢？

念茜的漫談iOS Crash收集框架闡述了兩者的關(guān)系，這里再重復(fù)下。

蘋果系統(tǒng)是基于Unix系統(tǒng)的，蘋果的大牛們?yōu)榱思嫒軺nix信號，將Mach異常轉(zhuǎn)化為Unix信號，并投射到異常的線程，這樣做的目的是：對于不懂Mach異常的人，也可以使用Unix信號捕獲異常。所以，Crash日志有兩種異常信息。

Mach和Unix關(guān)系圖：

image

所有Mach異常都在host層被ux_exception轉(zhuǎn)換為相應(yīng)的Unix信號，并通過threadsignal將信號投遞到出錯的線程。

捕獲Mach異?；蛘遀nix信號都可以抓到crash事件，這兩種方式哪個更好呢？

優(yōu)選Mach異常，因?yàn)镸ach異常的處理會先于Unix信號處理，如果Mach異常的handler讓程序exit了，那么Unix信號就永遠(yuǎn)不會到達(dá)這個進(jìn)程了。

所以，Crash日志中的EXC_BAD_ACCESS 是Mach異常信息，SIGSEGV是Unix信號異常信息。

小貼士:
因?yàn)橛布a(chǎn)生的信號(通過CPU陷阱)被Mach層捕獲，然后才轉(zhuǎn)換為對應(yīng)的Unix信號；蘋果為了統(tǒng)一機(jī)制，于是操作系統(tǒng)和用戶產(chǎn)生的信號(通過調(diào)用kill和pthread_kill)也首先沉下來被轉(zhuǎn)換為Mach異常，再轉(zhuǎn)換為Unix信號。

線程回溯

符號化回溯線程

線程的回溯是APP Crash瞬間，程序中所有線程的逆向調(diào)用堆棧。線程回溯對我們修復(fù)Crash非常有用，根據(jù)線程回溯，可以分析、定位程序崩潰的原因。

下面將崩潰的代碼、未符號化崩潰日志、符號化崩潰日志貼出來，做個對比性的理解。

@implementation ViewController

- (IBAction)onCrash:(__unused id)sender {
    char* ptr = (char*)-1;
    *ptr = 10;  ///這里程序崩潰了 
}

@end

未符號化的崩潰日志

image

符號化的崩潰日志

image

符號在二進(jìn)制中的偏移量

未符號化的崩潰日志中紅色文字展示了幾個名詞：鏡像文件、加載地址、堆棧地址。以及沒有展示出來的一個名詞：符號在二進(jìn)制中的偏移量。他們的含義分別為：

• 鏡像文件：是可執(zhí)行二進(jìn)制文件和二進(jìn)制文件依賴的動態(tài)庫的總稱。
• 堆棧地址：是代碼在內(nèi)存中執(zhí)行的內(nèi)存地址。
• 鏡像的加載地址：程序執(zhí)行時，內(nèi)核會將包含程序代碼的鏡像加載到內(nèi)存中，鏡像在內(nèi)存中的基地址就是加載地址。程序每次啟動時，鏡像的加載地址是隨機(jī)的。所以，同一代碼在不同的設(shè)備中執(zhí)行時，堆棧地址是不一樣的。
• 符號在二進(jìn)制中的偏移量：按照字面意思理解吧。它以通過下面的公式得到：

符號在二進(jìn)制中的偏移量 = 堆棧地址 - 鏡像的加載地址  

符號在二進(jìn)制中的偏移量非常有用，我們就是根據(jù)它，從符號文件中查找出地址對應(yīng)的代碼符號。這里的符號文件指的是：帶有符號表的可執(zhí)行二進(jìn)制文件、dSYM文件，這兩種文件在后續(xù)章節(jié)中都統(tǒng)稱為符號文件。

那么怎么將未符號化的崩潰日志符號化呢？

atos

蘋果自帶的atos命令行工具可以查找地址對應(yīng)的符號，在終端中輸入：

/usr/bin/atos -o [符號文件] -arch arm64 -l 0x100030000 0x000000010003522c 

輸出結(jié)果如下：

-[ViewController onCrash:] (in Simple-Example) (ViewController.m:10)

是不是很簡單的就將地址轉(zhuǎn)換為符號？是的，只需將符號文件（-o指定）、代碼構(gòu)架（-arch指定）、加載地址（-l指定）、堆棧地址傳入atos命令，就能解析出符號。

atos命令解析出了堆棧地址為0x000000010003522c、加載地址為0x100030000對應(yīng)的符號。符號為[ViewController onCrash:]，也驗(yàn)證了崩潰發(fā)生在onCrash函數(shù)中，也驗(yàn)證了崩潰日志中的地址是可以符號化的。

符號化原理是什么？怎么就通過地址找到了Crash代碼的符號，這就涉及符號化內(nèi)幕。

符號化內(nèi)幕

符號化的內(nèi)幕就是：==在符號文件中，通過偏移量查找符號==。下面，一步步的來分析，首先計算Crash地址在符號文件中的偏移量，為000000010000522c。

符號在二進(jìn)制中的偏移量 = 堆棧地址 - 鏡像的加載地址 = 0x000000010003522c -  0x100030000 = 000000010000522c

在符號文件中直接找地址000000010000522c，應(yīng)該是找不到，在后續(xù)你可以理解。我們使用逆向方法，根據(jù)符號-[ViewController onCrash:]，找對應(yīng)的地址，比較是不是000000010000522c，如果是，就充分說明了，通過偏移量是可以查找到內(nèi)存地址對應(yīng)的符號的。在終端中輸入下面的命令：

nm [符號文件] | grep "ViewController onCrash:"

輸出如下

00008320 t -[ViewController onCrash:]
0000000100005224 t -[ViewController onCrash:]

輸出的第一行是armv7s構(gòu)架的符號，第二行是arm64構(gòu)架的符號，Crash日志顯示的代碼構(gòu)架是arm64，使用第二行，符號-[ViewController onCrash:]對應(yīng)的偏移量是0000000100005224，而不是 000000010000522c，這個公式是在stack overflow上找到的，就相差8！后來寫日志組織測試用例的時候，忽然明白了為什么差那一點(diǎn)點(diǎn)。

原來，我們通過nm命令查找出的符號地址對，是函數(shù)入口地址和對應(yīng)的函數(shù)調(diào)用的符號對，僅僅是函數(shù)調(diào)用的符號，沒有函數(shù)內(nèi)部代碼的符號，而程序是崩潰到函數(shù)內(nèi)部，崩潰到*ptr = 10這句話，內(nèi)部代碼的地址怎么可能和入口地址一樣呢！相差一點(diǎn)點(diǎn)！

下面根據(jù)偏移量000000010000522c和代碼推算函數(shù)的入口地址吧，看看是什么。崩潰代碼*ptr = 10前面只有一個語句—定義初始化指針char* ptr = (char*)-1，在64位系統(tǒng)上指針的地址占8個字節(jié)，000000010000522c - 8= 0000000100005224，果然是0000000100005224。

這個不就是函數(shù)的入口地址嘛。原來那一點(diǎn)點(diǎn)的原因在這里。那么偏移量0000000100005224 對應(yīng)的符號正是-[ViewController onCrash:]。

上面通過nm 命令查找符號可能不直觀，可以通過可視化工具MachOView查看。驗(yàn)證下吧，選擇 Debug Symbols（ARM64_ALL）->Symbol Table->Symbols,然后在右上角的搜索框中輸入符號：-[ViewController onCrash:]，結(jié)果如下:

image

通過這個工具可以直觀的查看到符號和地址的對應(yīng)關(guān)系。

小小結(jié)

終于把符號化和符號化原理闡述完了簡單回顧下：

1. 可以通過系統(tǒng)的atos符號化崩潰日志的單個符號
2. 符號化內(nèi)部原理就是：根據(jù)符號在二進(jìn)制中的偏移量，在符號文件中查找對應(yīng)的符號。其中：==符號在二進(jìn)制中的偏移量 = 堆棧地址 - 鏡像的加載地址==。

線程的狀態(tài)寄存器

Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x000000010050b460   x1: 0x0000000100102cea   x2: 0x00000001004339d0   x3: 0x00000001740f8f00
    x4: 0x00000001740f8f00   x5: 0x00000001740f8f00   x6: 0x0000000000000001   x7: 0x0000000000000000
    x8: 0xffffffffffffffff   x9: 0x000000000000000a  x10: 0x00000001b3ad0018  x11: 0x00c1580100c15880
   x12: 0x0000000000c15800  x13: 0x0000000000c15900  x14: 0x0000000000c158c0  x15: 0x0000000000c15801
   x16: 0x0000000000000000  x17: 0x00000001000c1224  x18: 0x0000000000000000  x19: 0x00000001740f8f00
   x20: 0x00000001004339d0  x21: 0x0000000100102cea  x22: 0x000000010050b460  x23: 0x0000000170240bd0
   x24: 0x000000017400db90  x25: 0x0000000000000001  x26: 0x0000000000000000  x27: 0x00000001b2822000
   x28: 0x0000000000000040   fp: 0x000000016fd41ab0   lr: 0x0000000194aea7b0
    sp: 0x000000016fd41a90   pc: 0x00000001000c122c cpsr: 0x60000000

這是APP crash的時候，ARM64 構(gòu)架CPU的32個寄存器的值， 其中 fp 幀指針、sp 堆棧指針，lr 是返回地址指針，這三個都比較有用，用來逐級回溯線程調(diào)用棧。

Binary Images

image

鏡像文件就是上面講的可執(zhí)行程序 和 依賴的所有動態(tài)庫。

鏡像文件中包括鏡像的加載地址，和線程回溯中的鏡像加載地址指的是一個地址。加載地址后面有個UUID，符號文件中也有個UUID，只有這兩個地址一致，才能解析出地址對應(yīng)的符號。符號文件中的UUID可以通過終端中輸入下面的命令得到：

dwarfdump —u [符號文件]

輸出如下：

UUID: C8E0E6E4-F761-3A19-B231-A31C1BB9037A (armv7) 
UUID: 39BBB8F4-CCB0-3193-8491-C007931CA05E (arm64) 

第二行的arm64構(gòu)架的UUID居然和圖8中的紅色矩形框中UUID必須一致，這才表示代碼對應(yīng)的符號能在這個符號文件中找到，如果不一致，就沒法解析出地址對應(yīng)的符號。不論是Xcode，還是symbolicatecrash，都解析不了。

也可以通過MachOView查看符號文件的UUID，結(jié)果如下：

image

小結(jié)

這里闡述了日志的產(chǎn)生原因和符號化崩潰日志的原理。同時提及了幾個有用的工具：

1. file 文件類型顯示工具（The file-type displaying tool，位于/usr/bin/file）;
2. atos (將數(shù)字地址轉(zhuǎn)換為鏡像或可執(zhí)行程序中的符號工具，convert numeric addresses to symbols of binary images or processes，位于/usr/bin/atos);
3. nm（符號表展示工具，The symbol table display tool,位于 /usr/bin/nm）;
4. 可視化查看Mach-O工具，MachOView