- iOS Crash 流程化3:Crash 產生和符號化的原理
- 異常類型
- Mach異常
- Unix信號
- 異常的產生
- 線程回溯
- 符號化回溯線程
- 符號在二進制中的偏移量
- atos
- 符號化回溯線程
- 符號化內幕
- 小小結
- 線程的狀態寄存器
- Binary Images
- 小結
- 異常類型
iOS 的異常類型(Exception Type)由兩部分構成:Mach異常、Unix信號異常。
異常類型
Mach異常
蘋果系統有一個微內核,叫做XNU,它的源碼可以在opensource上下載到。Mach是XNU的核心,因而,Mach異常就指Mach內核異常。Mach包含三部分內容:thread,task,host。后續的章節中很多地方都會用到Mach。不妨移步到Mach IPC Interface,了解下Mach暴露給用戶的API。
Mach暴露給了用戶部分API,允許用戶和內核交互。用戶態的開發者可以通過Mach API設置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信號
信號是通知進程已發生某種情況的軟中斷技術。例如:某個進程執行了除法操作,其除數為0,則將名為SIGFPE(浮點異常)的信號發送給該進程。
異常的產生
那么,怎么會有兩種異常信息呢?
念茜的漫談iOS Crash收集框架闡述了兩者的關系,這里再重復下。
蘋果系統是基于Unix系統的,蘋果的大牛們為了兼容Unix信號,將Mach異常轉化為Unix信號,并投射到異常的線程,這樣做的目的是:對于不懂Mach異常的人,也可以使用Unix信號捕獲異常。所以,Crash日志有兩種異常信息。
Mach和Unix關系圖:
所有Mach異常都在host層被ux_exception轉換為相應的Unix信號,并通過threadsignal將信號投遞到出錯的線程。
捕獲Mach異常或者Unix信號都可以抓到crash事件,這兩種方式哪個更好呢?
優選Mach異常,因為Mach異常的處理會先于Unix信號處理,如果Mach異常的handler讓程序exit了,那么Unix信號就永遠不會到達這個進程了。
所以,Crash日志中的EXC_BAD_ACCESS 是Mach異常信息,SIGSEGV是Unix信號異常信息。
小貼士:
因為硬件產生的信號(通過CPU陷阱)被Mach層捕獲,然后才轉換為對應的Unix信號;蘋果為了統一機制,于是操作系統和用戶產生的信號(通過調用kill和pthread_kill)也首先沉下來被轉換為Mach異常,再轉換為Unix信號。
線程回溯
符號化回溯線程
線程的回溯是APP Crash瞬間,程序中所有線程的逆向調用堆棧。線程回溯對我們修復Crash非常有用,根據線程回溯,可以分析、定位程序崩潰的原因。
下面將崩潰的代碼、未符號化崩潰日志、符號化崩潰日志貼出來,做個對比性的理解。
@implementation ViewController
- (IBAction)onCrash:(__unused id)sender {
char* ptr = (char*)-1;
*ptr = 10; ///這里程序崩潰了
}
@end
未符號化的崩潰日志
符號化的崩潰日志
符號在二進制中的偏移量
未符號化的崩潰日志中紅色文字展示了幾個名詞:鏡像文件、加載地址、堆棧地址。以及沒有展示出來的一個名詞:符號在二進制中的偏移量。他們的含義分別為:
- 鏡像文件:是可執行二進制文件和二進制文件依賴的動態庫的總稱。
- 堆棧地址:是代碼在內存中執行的內存地址。
- 鏡像的加載地址:程序執行時,內核會將包含程序代碼的鏡像加載到內存中,鏡像在內存中的基地址就是加載地址。程序每次啟動時,鏡像的加載地址是隨機的。所以,同一代碼在不同的設備中執行時,堆棧地址是不一樣的。
- 符號在二進制中的偏移量:按照字面意思理解吧。它以通過下面的公式得到:
符號在二進制中的偏移量 = 堆棧地址 - 鏡像的加載地址
符號在二進制中的偏移量非常有用,我們就是根據它,從符號文件中查找出地址對應的代碼符號。這里的符號文件指的是:帶有符號表的可執行二進制文件、dSYM文件,這兩種文件在后續章節中都統稱為符號文件。
那么怎么將未符號化的崩潰日志符號化呢?
atos
蘋果自帶的atos命令行工具可以查找地址對應的符號,在終端中輸入:
/usr/bin/atos -o [符號文件] -arch arm64 -l 0x100030000 0x000000010003522c
輸出結果如下:
-[ViewController onCrash:] (in Simple-Example) (ViewController.m:10)
是不是很簡單的就將地址轉換為符號?是的,只需將符號文件(-o指定)、代碼構架(-arch指定)、加載地址(-l指定)、堆棧地址傳入atos命令,就能解析出符號。
atos命令解析出了堆棧地址為0x000000010003522c、加載地址為0x100030000對應的符號。符號為[ViewController onCrash:],也驗證了崩潰發生在onCrash函數中,也驗證了崩潰日志中的地址是可以符號化的。
符號化原理是什么?怎么就通過地址找到了Crash代碼的符號,這就涉及符號化內幕。
符號化內幕
符號化的內幕就是:==在符號文件中,通過偏移量查找符號==。下面,一步步的來分析,首先計算Crash地址在符號文件中的偏移量,為000000010000522c。
符號在二進制中的偏移量 = 堆棧地址 - 鏡像的加載地址 = 0x000000010003522c - 0x100030000 = 000000010000522c
在符號文件中直接找地址000000010000522c,應該是找不到,在后續你可以理解。我們使用逆向方法,根據符號-[ViewController onCrash:],找對應的地址,比較是不是000000010000522c,如果是,就充分說明了,通過偏移量是可以查找到內存地址對應的符號的。在終端中輸入下面的命令:
nm [符號文件] | grep "ViewController onCrash:"
輸出如下
00008320 t -[ViewController onCrash:]
0000000100005224 t -[ViewController onCrash:]
輸出的第一行是armv7s構架的符號,第二行是arm64構架的符號,Crash日志顯示的代碼構架是arm64,使用第二行,符號-[ViewController onCrash:]對應的偏移量是0000000100005224,而不是 000000010000522c,這個公式是在stack overflow上找到的,就相差8!后來寫日志組織測試用例的時候,忽然明白了為什么差那一點點。
原來,我們通過nm命令查找出的符號地址對,是函數入口地址和對應的函數調用的符號對,僅僅是函數調用的符號,沒有函數內部代碼的符號,而程序是崩潰到函數內部,崩潰到*ptr = 10
這句話,內部代碼的地址怎么可能和入口地址一樣呢!相差一點點!
下面根據偏移量000000010000522c和代碼推算函數的入口地址吧,看看是什么。崩潰代碼*ptr = 10
前面只有一個語句—定義初始化指針char* ptr = (char*)-1
,在64位系統上指針的地址占8個字節,000000010000522c - 8= 0000000100005224,果然是0000000100005224。
這個不就是函數的入口地址嘛。原來那一點點的原因在這里。那么偏移量0000000100005224 對應的符號正是-[ViewController onCrash:]
。
上面通過nm 命令查找符號可能不直觀,可以通過可視化工具MachOView查看。驗證下吧,選擇 Debug Symbols(ARM64_ALL)->Symbol Table->Symbols
,然后在右上角的搜索框中輸入符號:-[ViewController onCrash:]
,結果如下:
通過這個工具可以直觀的查看到符號和地址的對應關系。
小小結
終于把符號化和符號化原理闡述完了簡單回顧下:
- 可以通過系統的atos符號化崩潰日志的單個符號
- 符號化內部原理就是:根據符號在二進制中的偏移量,在符號文件中查找對應的符號。其中:==符號在二進制中的偏移量 = 堆棧地址 - 鏡像的加載地址==。
線程的狀態寄存器
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 構架CPU的32個寄存器的值, 其中 fp 幀指針、sp 堆棧指針,lr 是返回地址指針,這三個都比較有用,用來逐級回溯線程調用棧。
Binary Images
鏡像文件就是上面講的可執行程序 和 依賴的所有動態庫。
鏡像文件中包括鏡像的加載地址,和線程回溯中的鏡像加載地址指的是一個地址。加載地址后面有個UUID,符號文件中也有個UUID,只有這兩個地址一致,才能解析出地址對應的符號。符號文件中的UUID可以通過終端中輸入下面的命令得到:
dwarfdump —u [符號文件]
輸出如下:
UUID: C8E0E6E4-F761-3A19-B231-A31C1BB9037A (armv7)
UUID: 39BBB8F4-CCB0-3193-8491-C007931CA05E (arm64)
第二行的arm64構架的UUID居然和圖8中的紅色矩形框中UUID必須一致,這才表示代碼對應的符號能在這個符號文件中找到,如果不一致,就沒法解析出地址對應的符號。不論是Xcode,還是symbolicatecrash,都解析不了。
也可以通過MachOView查看符號文件的UUID,結果如下:
小結
這里闡述了日志的產生原因和符號化崩潰日志的原理。同時提及了幾個有用的工具:
- file 文件類型顯示工具(The file-type displaying tool,位于/usr/bin/file);
- atos (將數字地址轉換為鏡像或可執行程序中的符號工具,convert numeric addresses to symbols of binary images or processes,位于/usr/bin/atos);
- nm(符號表展示工具,The symbol table display tool,位于 /usr/bin/nm);
- 可視化查看Mach-O工具,MachOView