https://blog.csdn.net/mkhgg/article/details/17247673

如果是完整的*.crash log，就使用Symbolicatecrash來解析， 使用方法：

1. 找到Symbolicatecrash檔案

Xcode 5.0的之後

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/

（附：Mac系統顯示隱藏檔案

終端中輸入以下命令

顯示Mac隱藏檔案的命令：defaults write com.apple.finder AppleShowAllFiles -bool true

隱藏Mac隱藏檔案的命令：defaults write com.apple.finder AppleShowAllFiles -bool false

輸入完回車，重啟Finder：左上角的蘋果標誌-->強制退出-->Finder-->重新啟動

）

2. Symbolicatecrash檔案獨立於Xcode，可以拷出來使用，附件中為Xcode4.5中的Symbolicatecrash檔案

3. 命終端中輸入命令，命令格式：Symbolicatecrash .crash .dSYM > aa.log

即：Symbolicatecrash + 崩潰日誌 + APP對應的.dSYM檔案 + > + 輸出到的檔案

4. 如果提示"DEVELOPER_DIR" is not defined

在終端中輸入： export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

///————————————————————

根據UncaughtExceptionHandler report crash log（即不是完整的 *.crash檔案的時候，而是自己捕捉到的異常發給伺服器以便分析） 的地址解析出對於程式位置的方法：

－、第一種情況：

1、計算symbol address

如果從report crash log得到的資訊如下：

0 MyDJ 0x001b27d7 MyDJ + 1394647

1 MyDJ 0x001b2f05 MyDJ + 1396485

symbol address = 1394647(地址偏移量，相對起始地址（下面會介紹如何獲取此地址）) ＋ 起始地址

2、起始地址：即使每次iOS app啟動都會載入(main module)主模組在不同的記憶體地址，但是dSYM檔案假設你的main module載入在地址0x1000（大多數情況是這個，也有0x4000的）。

獲取此地址的方法：The slide value is the value of vmaddr in LC_SEGMENT cmd (Mostly this is 0x1000)

NapoleonmatoMac-mini:~ cnstar-tech$ otool -arch armv7 -l /Users/cnstar-tech/crash/MyDJ.app/MyDJ  | grep -B 1 -A 10 "LC_SEGM" | grep -B 3 -A 8 "__TEXT"

Load command 1

     cmd LC_SEGMENT

 cmdsize 736

 segname __TEXT

  vmaddr 0x00004000

  vmsize 0x001ec000

 fileoff 0

filesize 2015232

 maxprot 0x00000005

initprot 0x00000005

  nsects 10

   flags 0x0

“ vmaddr 0x00004000” 此地址便為app執行的起始地址。

1394647 ＋ 0x4000 = 0x1587d7 (symbol address)

3、最後解析此地址：

NapoleonmatoMac-mini:~ cnstar-tech$ xcrun atos -arch armv7 -o /Users/cnstar-tech/crash/MyDJ.app/MyDJ 0x1587d7

+[UncaughtExceptionHandler backtrace] (in MyDJ) (UncaughtExceptionHandler.m:29)

“+[UncaughtExceptionHandler backtrace] (in MyDJ) (UncaughtExceptionHandler.m:29)” 這個便是最後解析結果

二、第二種情況：

如果從crash log得到的對於的資訊如下：

7   MyDJ                          0x000896e2 0x19000 + 460514

8   MyDJ                          0x000e5934 0x19000 + 837940

9   MyDJ                          0x000e585e 0x19000 + 837726

這種情況便無需計算symbol address，可以直接使用－load address相對偏移進行解析

命令如下：

NapoleonmatoMac-mini:~ cnstar-tech$ xcrun atos -arch armv7s -o /Users/cnstar-tech/crash/MyDJ.app/MyDJ -l 0x19000 0x000896e2

got symbolicator for /Users/cnstar-tech/crash/MyDJ.app/MyDJ, base address 4000

-[HTTPFetcher startWithUrlString:rangeFrom:to:receiver:action:] (in MyDJ) (HTTPFetcher.m:288)

看到沒？同樣解析出來了。

下面使用第一種情況的辦法進行解析並對比是否一致吧：

460514 ＋ 0x4000 = 0x746e2

NapoleonmatoMac-mini:~ cnstar-tech$ xcrun atos -arch armv7s -o /Users/cnstar-tech/crash/MyDJ.app/MyDJ 0x746e2

-[HTTPFetcher startWithUrlString:rangeFrom:to:receiver:action:] (in MyDJ) (HTTPFetcher.m:288)

可見以上兩中解析方法得到的結果是一致的，具體使用哪種就要看具體資訊了

三、第三種
如果從report crash log得到的資訊如下：
0 MyDJ 0x001b27d7 MyDJ + 1394647
1 MyDJ 0x001b2f05 MyDJ + 1396485
其實這種情況也可以用第二種情況的解析方法，這個時候就需要計算－load address了，計算方法(第一個地址－最後一個地址)：
－load address ＝ 0x001b27d7 － 1394647 ＝ 0x5e000
這時候便可以得到crash log資訊如下：
0 MyDJ 0x001b27d7 0x5e000 + 1394647
1 MyDJ 0x001b2f05 0x5e000 + 1396485

這時候使用第二中情況進行解析，結果如下：
NapoleonmatoMac-mini:~ cnstar-tech$ xcrun atos -arch armv7 -o /Users/cnstar-tech/crash/MyDJ.app/MyDJ -l 0x5e000 0x1b27d7
got symbolicator for /Users/cnstar-tech/crash/MyDJ.app/MyDJ, base address 4000
+[UncaughtExceptionHandler backtrace] (in MyDJ) (UncaughtExceptionHandler.m:29)

看到沒，其實跟第一種情況解析出來的結果是一致的。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
第三種方法其實比較常用，因為這種情況對於系統庫一樣適用，如有以下日誌（是從一個完整的 *.crash日誌裡面取出來的一條記錄）：
6   Foundation                     0x302ff692 0x302f4000 + 46738
這個經過計算後 －load address ＝ 0x302ff692 － 46738 ＝ 0x302f4000
解析結果如下：
NapoleonmatoMac-mini:~ cnstar-tech$ xcrun atos -arch armv7s -o /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/System/Library/Frameworks/Foundation.framework/Foundation -l 0x302f4000  0x302ff692
got symbolicator for /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/System/Library/Frameworks/Foundation.framework/Foundation, base address 0
-[NSRunLoop(NSRunLoop) runMode:beforeDate:] (in Foundation) + 250
－－－－－－－－－－－－－－－－－－－－－－－－
下面為使用symbolicatecrash解析後的結果：
6   Foundation                     0x302ff692 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 250

經過對比，兩種方法解析出來的結果也是一致的。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
綜上所述，以上所有情況與方法，最好的當數第三種了。

以上的方法都需要對應的dSym檔案，可以使用如下方法對比是否是匹配

MAC上有個免費的小工具——dwarfdump，可以簡便地檢測出app和相應的dSYM。
使用起來很簡單。分三步即可。
1> 根據crash log，得到App的UUID。UUID是個字串，由32個字元組成。得到了UUID，你才能知道是你的哪個版本在使用者的iPhone上出了問題。
2> 使用dwarfdump檢查app，看哪個app是上面那個UUID。命令列格式：
dwarfdump -u MyDJ.app/MyDJ
3> 用dwarfdump檢查dSYM檔案是否是上面的UUID。命令列格式：
dwarfdump -u MyDJ.app.dSYM
如果三者的UUID都是一致的，那麼恭喜你，該crash log可以被正確解析出來，stack traces資訊可以被正確地拿到。