dSYM atos crash log 定位到代碼行的方法(轉)

作iOS開發的時候，經常會遇到crash，須要分析call stack的時候。
有時候App在別人的設備崩潰，把crash report在本身的機器上打開，Xcode沒有自動的進行符號化。
這時候就須要本身去把地址解析成符號。
大前提是，必須有相同版本App對應的.dSYM文件。
這時候打開Terminal，進入到build/Debug-iphoneos
使用命令:
$atos -arch arm7 -o XXX.app/XXX 0xabcdef
XXX是你的App名字，用須要解析的地址替換上面的0xabcdef
arm7是編譯App時所用的Architecture，也多是arm6，若是在simulator上的App，這個位置應該用i386

 http://stackoverflow.com/questions/5175990/ambiguous-iphone-crash-report

 

搞iPhone開發就要不停地發版本，隨之而來的就是各類版本的crash log。若是不能好好地管理，那麼開發人員很快就會在crash log和版本的海洋裏迷失方向。
MAC上有個免費的小工具——dwarfdump，能夠簡便地檢測出app和相應的dSYM。
使用起來很簡單。分三步便可。
1> 根據crash log，獲得App的UUID。UUID是個字符串，由32個字符組成。獲得了UUID，你才能知道是你的哪一個版本在用戶的iPhone上出了問題。
2> 使用dwarfdump檢查app，看哪一個app是上面那個UUID。命令行格式：
dwarfdump --uuid YourApp.app/YourApp
3> 用dwarfdump檢查dSYM文件是不是上面的UUID。命令行格式：
dwarfdump --uuid YourApp.app.dSYM
若是三者的UUID都是一致的，那麼恭喜你，該crash log能夠被正確解析出來，stack traces信息能夠被正確地拿到。

 

 

 

 

 

當你編譯一個Objective-C程序時，代碼被轉換成2進制文件。可是和Java等其它語言不一樣，編譯沒法經過時，無法看出是哪裏出的問題。可是，編譯時會生成一個dSYM包。它能把編譯崩潰報告和代碼匹配起來，從而肯定問題所在。
問題是dSYM包必須和二進制文件匹配，因此每次代碼重建和版本變化時都要附帶重建dSYM包。這可夠麻煩的。爲此我寫了個腳本，它能把dSYM包移入文件目錄裏，生成一個叫「dSYM」的目錄項。此外，該腳本還能檢查並保存GIT裏的包。爲了防止2個包重名，腳本以生成時間來命名每一個dSYM包。
故障檢查
腳本的第一任務是檢查可否調試。

if [ "$BUILD_STYLE" == "Debug" ]; then
echo "Skipping debug"
exit 0;
fi
腳本的第一部分是
檢查該版本可否調試
。其實文件還在開發者電腦上，代碼也都在，這一步能夠略過了。
if [ "$EFFECTIVE_PLATFORM_NAME" == "-iphonesimulator" ]; then
echo "Skipping simulator build"
exit 0;
fi
第二步是檢查版本兼容性，先無論儲存代碼的事。
移動文件
既然dSYM是以生成時間命名的，而且能夠在開發者之間以及電腦間遷移，我把環境變量加入到文件裏。
SRC_PATH=${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}
RELATIVE_DEST_PATH=dSYM/${EXECUTABLE_NAME}.$(date +%Y%m%d%H%M%S).app.dSYM
DEST_PATH=${PROJECT_DIR}/${RELATIVE_DEST_PATH}
echo "moving ${SRC_PATH} to ${DEST_PATH}"
mv "${SRC_PATH}" "${DEST_PATH}"

下一步就是創建文件當前位置到轉存位置的路徑。最好把路徑存下來，出問題時好查看。
提交到版本控制
忙了半天，就是爲了這個版本控制啊。
if [ -f ".git/config" ]; then
git add "${RELATIVE_DEST_PATH}"
git commit -m "Added dSYM file for ${BUILD_STYLE} build" \
"${RELATIVE_DEST_PATH}"
fi
只有當項目是GIT包的一部分時才觸發最後這部分代碼。

首先須要兩個東西：
一、崩潰報告 .crash文件
    這個從手機上能夠找到，經過Organizer能夠導入導出
    其實須要這個文件，主要是爲了找到崩潰時的棧
    友盟統計的報告中，是沒有.crash文件的，只有棧信息，因此也足夠
二、該應用的 .dSYM文件
    這個文件和你編譯的應用二進制文件是一一對應的
    在你編譯的app文件同目錄下就能找到
    不過也沒必要擔憂上傳應用到app store時的那個對應的.dSYM沒保存
    在XCode4之後，有個archive功能，通常上傳應用前都會archive下
    在Organizer中找到相應的archive文件，查看包內容，裏面有咱們須要的.dSYM文件
兩個東西準備好後執行這個命令

XML/HTML代碼

1. atos -o /MyApp.dSYM/Contents/Resources/DWARF/MyApp -arch armv7 0x99999999 
   

三點說明：
一、/MyApp.dSYM/Contents/Resources/DWARF/MyApp
    就是那個.dSYM包（其實.dSYM是個包，不是二進制文件）中的文件路徑
    MyApp換成你的應用名稱便可
二、armv7
    根據你的應用，選擇6或7
三、0x99999999
    這個是在崩潰記錄中的代碼地址
    就是函數的入口地址
執行後，會顯示相應的函數名
由於是根據調用棧算出來的，因此只能定位到函數，沒法定位到具體代碼行
記得馬丁福勒的「重構書」嗎？裏面一直強調「小函數」
這裏爲他提供了一個論據






http://stackoverflow.com/questions/4604843/crash-log-in-device轉自:http://blog.sina.com.cn/s/blog_489ab04e010157pg.html