重點是dwarfdump --uuid命令
我們在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>
5.通過symbolicatecrash分析cras**件
該檔案是隱藏檔案，可以通過如下命令查詢並拷貝到系統目錄下，並建立快捷方式。
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和cras**件對應的資料夾目錄，如
cd ~/desktop/debuglog
9)執行如下命令，即可正確解析cras**件
注意：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.
今天就先到這裡，希望對大家有所幫助。
重點是dwarfdump --uuid命令
我們在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>
5.通過symbolicatecrash分析cras**件
該檔案是隱藏檔案，可以通過如下命令查詢並拷貝到系統目錄下，並建立快捷方式。
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和cras**件對應的資料夾目錄，如
cd ~/desktop/debuglog
9)執行如下命令，即可正確解析cras**件
注意：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
我們在ios開發中會碰到的很多crash問題，如果debug除錯模式的話，我們可以往往很容易的根據log的輸出定位到導致crash的原因，但對於已經上線的應用，或者是release環境包導致的crash，我們就需要一些特殊的手段來通過crash log進行分析定位了。通過參考網上的一些資料，總結了一...