iOS Crash 流程化3:Crash 產(chǎn)生和符號(hào)化的原理

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

iOS 的異常類(lèi)型(Exception Type)由兩部分構(gòu)成:Mach異常、Unix信號(hào)異常。

異常類(lèi)型

Mach異常

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

Mach暴露給了用戶(hù)部分API,允許用戶(hù)和內(nèi)核交互。用戶(hù)態(tài)的開(kāi)發(fā)者可以通過(guò)Mach API設(shè)置thread、task、host的異常端口,來(lái)捕獲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信號(hào)

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

異常的產(chǎn)生

那么,怎么會(huì)有兩種異常信息呢?

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

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

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


image

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

捕獲Mach異常或者Unix信號(hào)都可以抓到crash事件,這兩種方式哪個(gè)更好呢?

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

所以,Crash日志中的EXC_BAD_ACCESS 是Mach異常信息,SIGSEGV是Unix信號(hào)異常信息。

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

線(xiàn)程回溯

符號(hào)化回溯線(xiàn)程

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

下面將崩潰的代碼、未符號(hào)化崩潰日志、符號(hào)化崩潰日志貼出來(lái),做個(gè)對(duì)比性的理解。

@implementation ViewController

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

@end

未符號(hào)化的崩潰日志

image

符號(hào)化的崩潰日志

image

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

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

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

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

那么怎么將未符號(hào)化的崩潰日志符號(hào)化呢?

atos

蘋(píng)果自帶的atos命令行工具可以查找地址對(duì)應(yīng)的符號(hào),在終端中輸入:

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

輸出結(jié)果如下:

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

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

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

符號(hào)化原理是什么?怎么就通過(guò)地址找到了Crash代碼的符號(hào),這就涉及符號(hào)化內(nèi)幕。

符號(hào)化內(nèi)幕

符號(hào)化的內(nèi)幕就是:==在符號(hào)文件中,通過(guò)偏移量查找符號(hào)==。下面,一步步的來(lái)分析,首先計(jì)算Crash地址在符號(hào)文件中的偏移量,為000000010000522c。

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

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

nm [符號(hào)文件] | grep "ViewController onCrash:"

輸出如下

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

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

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

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

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

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

image

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

小小結(jié)

終于把符號(hào)化和符號(hào)化原理闡述完了簡(jiǎn)單回顧下:

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

線(xià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的時(shí)候,ARM64 構(gòu)架CPU的32個(gè)寄存器的值, 其中 fp 幀指針、sp 堆棧指針,lr 是返回地址指針,這三個(gè)都比較有用,用來(lái)逐級(jí)回溯線(xiàn)程調(diào)用棧。

Binary Images

image

鏡像文件就是上面講的可執(zhí)行程序依賴(lài)的所有動(dòng)態(tài)庫(kù)

鏡像文件中包括鏡像的加載地址,和線(xiàn)程回溯中的鏡像加載地址指的是一個(gè)地址。加載地址后面有個(gè)UUID,符號(hào)文件中也有個(gè)UUID,只有這兩個(gè)地址一致,才能解析出地址對(duì)應(yīng)的符號(hào)。符號(hào)文件中的UUID可以通過(guò)終端中輸入下面的命令得到:

dwarfdump —u [符號(hào)文件]

輸出如下:

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

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

也可以通過(guò)MachOView查看符號(hào)文件的UUID,結(jié)果如下:

image

小結(jié)

這里闡述了日志的產(chǎn)生原因和符號(hào)化崩潰日志的原理。同時(shí)提及了幾個(gè)有用的工具:

  1. file 文件類(lèi)型顯示工具(The file-type displaying tool,位于/usr/bin/file);
  2. atos (將數(shù)字地址轉(zhuǎn)換為鏡像或可執(zhí)行程序中的符號(hào)工具,convert numeric addresses to symbols of binary images or processes,位于/usr/bin/atos);
  3. nm(符號(hào)表展示工具,The symbol table display tool,位于 /usr/bin/nm);
  4. 可視化查看Mach-O工具,MachOView
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀(guān)點(diǎn),簡(jiǎn)書(shū)系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,797評(píng)論 6 531
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,179評(píng)論 3 414
  • 文/潘曉璐 我一進(jìn)店門(mén),熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人,你說(shuō)我怎么就攤上這事。” “怎么了?”我有些...
    開(kāi)封第一講書(shū)人閱讀 175,628評(píng)論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀(guān)的道長(zhǎng)。 經(jīng)常有香客問(wèn)我,道長(zhǎng),這世上最難降的妖魔是什么? 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 62,642評(píng)論 1 309
  • 文/花漫 我一把揭開(kāi)白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開(kāi)封第一講書(shū)人閱讀 54,948評(píng)論 1 321
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,040評(píng)論 3 440
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來(lái)了?” 一聲冷哼從身側(cè)響起,我...
    開(kāi)封第一講書(shū)人閱讀 42,185評(píng)論 0 287
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒(méi)想到半個(gè)月后,有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,717評(píng)論 1 333
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 40,602評(píng)論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 42,794評(píng)論 1 369
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,316評(píng)論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,045評(píng)論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 34,418評(píng)論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 35,671評(píng)論 1 281
  • 我被黑心中介騙來(lái)泰國(guó)打工, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 51,414評(píng)論 3 390
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 47,750評(píng)論 2 370

推薦閱讀更多精彩內(nèi)容

  • [這是第14篇] 序: iOS Crash問(wèn)題是iOS開(kāi)發(fā)中難以忽視的存在,本文就捕獲iOS Crash、Cras...
    南華coder閱讀 9,914評(píng)論 21 116
  • 本文就捕獲iOS Crash、Crash日志組成、Crash日志符號(hào)化、異常信息解讀、常見(jiàn)的Crash五部分介紹。...
    xukuangbo_閱讀 1,591評(píng)論 0 0
  • Ref:iOS Crash 捕獲及堆棧符號(hào)化思路剖析 iOS Crash 流程化:概覽崩潰捕獲Mach 異常捕獲U...
    Vinc閱讀 1,346評(píng)論 0 0
  • 《泥步修行》這本書(shū)是我第一次通過(guò)正版購(gòu)買(mǎi)的方式獲取的余老著作,算是對(duì)余老遲到的敬意吧。余老師的書(shū),我讀過(guò)了不少,深...
    放縱天涯閱讀 1,053評(píng)論 0 0
  • 已默認(rèn)讀者了解本篇自言自語(yǔ)的context,且對(duì)于module有所了解,對(duì)于module的相關(guān)擴(kuò)展說(shuō)明將穿插在內(nèi)容...
    蔣啟鉦閱讀 1,118評(píng)論 0 4