iOS 崩潰日誌 Backtrace的符號化

iOS 崩潰日誌 Backtrace的符號化

iOS的崩潰日誌配合dsym檔案可以找到崩潰時的backtrace,這是解決崩潰的最重要的資訊.

如果是在同一台mac上打包, 匯入crash log時候會自動將backtrace符號化,可以看到方法名, 檔案名稱和行號

但是,有時候發版的包不是在你的mac上打包的,xcode找不到對應的符號表, backtrace沒能符號化如下所示:

Last Exception Backtrace:
0 CoreFoundation 0x2cb535f2 __exceptionPreprocess + 122
1 libobjc.A.dylib 0x3a3c5c72 objc_exception_throw + 34
2 CoreFoundation 0x2ca67152 -[__NSArrayM objectAtIndex:] + 226
3 myapp 0x004fe736 0x9b000 + 4601654
4 myapp 0x00507ed4 0x9b000 + 4640468
5 myapp 0x004fd112 0x9b000 + 4595986
6 myapp 0x003275c6 0x9b000 + 2672070

這裡第二行可以看到是一個數組objectAtIndex拋出異常,但是3-6行的是來自應用自己的代碼myapp, 這些資訊才是最重要的.

其實,只要有原app檔案,是可以將這些資訊找到.

方法:

將對應版本的myapp.app檔案和crash檔案放在同一個檔案夾下, 注意,一定要是該應用正確版本的app, 因為每次打包, 符號表的映射關係都有可能不同,如果不對應的話是沒法符號化的.

然後運行

atos -arch armv7 -o myapp.app/myapp -l 0x9b000 0x004fe736

這個方法 -arch後面是指硬體架構:
iphone 1,2,3 是armv6
iphone4,4s 是 armv7
iphone5,5c是armv7s
iphone 5s, 6, 6+, 6s, 6s+ 是arm64

根據崩潰發生的裝置來選擇上述架構, myapp.app就是你的app的檔案名稱, 選項l後面的兩個16進位數是關鍵:
第一個數字,取backtrace的要解析的行的第4列, 第二個數字取第3列, 就會得到對應的方法名,檔案名稱,行號.
這樣,可以將上述3-6行中一行一行的解析出來,就能看到發生崩潰的地方,再進行分析就簡單了.