版本記錄
| 版本號 | 時間 |
|---|---|
| V1.0 | 2021.11.20 星期六 |
前言
程序總會有bug，如果有好的調試技巧和方法，那麼就是事半功倍，這個專題專門和大家分享下和調試相關的技巧。希望可以幫助到大家。感興趣的可以看下面幾篇文章。
1. 程序調試 （一） —— App Crash的調試和解決示例（一）
2. 程序調試 （二） —— Xcode Simulator的高級功能（一）
3. 程序調試 （三） —— Xcode Simulator的高級功能（二）
4. 程序調試 （四） —— Xcode內存管理（一）
5. 程序調試 （五） —— 使用Build Configurations 和 .xcconfig 構建你的App（一）
6. 程序調試 （六） —— 使用Build Configurations 和 .xcconfig 構建你的App（二）
7. 程序調試 （七） —— 基於iOS的Charles Proxy教程（一）
8. 程序調試 （八） —— 基於iOS的高級Charles Proxy教程（一）
9. 程序調試 （九） —— Crash日誌的獲取和符號解析（一）
開始
上面一篇程序調試 （九） —— Crash日誌的獲取和符號解析（一）我們介紹了崩潰的解析。
那個是使用了symbolicatecrash進行dSYM包進行反解析。下面我們看另外一個方法。
首先我們還是看下未解析過的崩潰日誌。
這裏需要注意一下，紅色框框裏面的就是我的App相關的崩潰信息。特別要注意地址0x0000000106371584 0x100ffc000。其中0x100ffc000是程序基地址，0x0000000106371584是方法的堆棧地址。
接着找到一個dSYM包，右擊並選擇顯示包內容。
可以看見下面的文件目錄
下面我們不用symbolicatecrash進行dSYM包進行反解析，直接用命令行進行解析下。
在終端進入到dSYM的路徑
輸入下面指令
dwarfdump --uuid xxx.app.dSYM
可以得到下面輸出
可以看見是arm64結構的。
下面繼續輸入
//xxx就是自己app包名
atos -arch arm64 -o xxx.app.dSYM/Contents/Resources/DWARF/xxx -l 0x100ffc000 0x0000000106371584
看下面的輸出
可以看見是崩潰在C++了。但是看不出來具體是咋回事，這裏只是講述了一種方法，雖然這裏還看不出來原因。下面我們就用symbolicatecrash進行dSYM包進行反解析來驗證這個方法的輸出是否正確。
symbolicatecrash反解析出來如下所示：
這就反向證明，上面那個方法解析也是可以的。
後記
本篇主要講述了
Crash日誌的另外一種解析方法，感興趣的給個贊或者關注~~~
