專案整合talkingdata收集到的crash日誌, 看到那些日誌時自己也是很崩潰, 全是記憶體位址, 根本搞不懂專案到底crash到了那裡,
比如這樣:
自己在網上找了很多方法, 以下是自己最後所用到的方法(心累):
2, 對.dsym檔案顯示包內容, 找到dwarf資料夾
路徑:
.dsym/contents/resources/dwarf
在終端終端中cd到
dwarf資料夾
3, 終端輸入命令列:
1000c8000
0x000000010058bb1c
其中 ******為專案名
1000c8000為 16進製制記憶體位址-10進製偏移量所得到的16進製制數值
0x000000010058bb1c 16進製制記憶體位址
4,回車得到的即為自己要的錯誤資訊, 如下:
就這些了....
雖然其中的進製間演算法很坑爹 但是確實很實用的一種方法,
其實還可以通過**幫忙去算的, 具體怎麼搞就不囉嗦了....
iOS Crash檔案分析
具體步驟 2.找到崩潰日誌 crash檔案 如果確定直接到步驟4 3.如果uuid相同你就可以進行下面的工作了 5.然後用dwarfdump 命令如果運氣好就能找出對於記憶體位址在 中的位置，否則就悲慘了。這個需要在命令列操作 6.最後就是找 檢視bug ps 如果出現找不到symbolicatec...
ios crash檔案分析
ios程式在真機執行程式出現crash狀況時，機器會自動產生log檔案，它包含了在程式crash之前的執行邏輯，分析carsh檔案，有效的解決程式在真機上的問題，保證程式良好的穩定性,但是這個crash檔案多數是顯示出現問題的位址和一些系統的訊息，無法檢視程式中對應的崩潰地點，以下文章幫你解決這個問...
iOS Crash 分析（文三） 符號化崩潰日誌
未符號化的崩潰日誌就象一本天書，看不懂，更別談分析崩潰原因了。所以我們在分析日誌之前，要把日誌翻譯成我們可以看得懂的文字。這一步我們稱之為符號化。在ios crash分析 文一 中已經提到過符號化的兩種方式 1.利用xcode符號化 2.利用symbolicatecrash指令碼符號化 其實這兩種分...