iOS通過dSYM檔案分析crash

2021-07-02 18:44:39 字數 1919 閱讀 7471

我們在ios開發中會碰到的很多crash問題,如果debug除錯模式的話,我們可以往往很容易的根據log的輸出定位到導致crash的原因,但對於已經上線的應用,或者是release環境包導致的crash,我們就需要一些特殊的手段來通過crash log進行分析定位了。

通過參考網上的一些資料,總結了一下,下面介紹一下通過dsym檔案以及crash log分析定位的方法。

1.匯出crash log

通過xcode的organizer檢視某台iphone裝置的devicelog,選擇需要的crash log,匯出***.crash檔案。

3.找到對應build版本的dsym檔案

而.crash的uuid位於,crash日誌中的binary images:中的第一行。如:

armv7 <8bdeaf1a0b233ac199728c2a0ebb4165>

檔案以及

***.crash檔案拷貝到同一資料夾中,如:~/desktop/debuglog。

5.通過symbolicatecrash分析crash檔案

該檔案是隱藏檔案,可以通過如下命令查詢並拷貝到系統目錄下,並建立快捷方式。

1)開啟終端,進入到symbolicatecrash工具所在的資料夾目錄

2)查詢確認是否存在symbolicatecrash

ls -al | grep symbolicatecrash

3)將symbolicatecrash工具拷貝到/usr/bin目錄下

sudo cp symbolicatecrash /usr/bin/symbolicatecrash

4)設定developer_dir系統變數

cd ~/

vi .bash_profile

並輸入如下內容

儲存並退出

source .bash_profile

5)重啟終端,確認是否已正確設定developer_dir系統變數

echo $developer_dir

6)檢視path系統變數是否存在如下路徑/usr/bin

echo $path

7)如果path不存在如下路徑/usr/bin,可在~/.bash_profile中新增如下**

export path="/usr/bin:$path"

儲存並退出

source .bash_profile

8)上述準備工作完成後,進入dsym和crash檔案對應的資料夾目錄,如

cd ~/desktop/debuglog

9)執行如下命令,即可正確解析crash檔案

注意:symbolicatecrash的引數順序,否則會報類似如下錯誤

use of uninitialized value $data in substitution (s///) at /usr/bin/symbolicatecrash line 678.

use of uninitialized value $data in substitution (s///) at /usr/bin/symbolicatecrash line 681.

use of uninitialized value $data in substitution (s///) at /usr/bin/symbolicatecrash line 685.

use of uninitialized value in pattern match (m//) at /usr/bin/symbolicatecrash line 404.

use of uninitialized value in scalar assignment at /usr/bin/symbolicatecrash line 418.

今天就先到這裡,希望對大家有所幫助。

iOS通過dSYM檔案分析crash

重點是dwarfdump uuid命令 我們在ios開發中會碰到的很多crash問題,如果debug除錯模式的話,我們可以往往很容易的根據log的輸出定位到導致crash的原因,但對於已經上線的應用,或者是release環境包導致的crash,我們就需要一些特殊的手段來通過crash log進行分析...

iOS通過dSYM檔案分析crash

重點是dwarfdump uuid命令 我們在ios開發中會碰到的很多crash問題,如果debug除錯模式的話,我們可以往往很容易的根據log的輸出定位到導致crash的原因,但對於已經上線的應用,或者是release環境包導致的crash,我們就需要一些特殊的手段來通過crash log進行分析...

iOS通過dSYM檔案分析crash

重點是dwarfdump uuid命令 我們在ios開發中會碰到的很多crash問題,如果debug除錯模式的話,我們可以往往很容易的根據log的輸出定位到導致crash的原因,但對於已經上線的應用,或者是release環境包導致的crash,我們就需要一些特殊的手段來通過crash log進行分析...