溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

使用Symbolicatecrash和xcrun atos分析crash log

發(fā)布時間:2020-07-22 06:30:21 來源:網(wǎng)絡 閱讀:1736 作者:命苦 欄目:移動開發(fā)

如果是完整的*.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系統(tǒng)顯示隱藏文件

終端中輸入以下命令

顯示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




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

根據(jù)UncaughtExceptionHandler report crash log(即不是完整的 *.crash文件的時候,而是自己捕捉到的異常發(fā)給服務器以便分析) 的地址解析出對于程序位置的方法:


-、第一種情況:


1、計算symbol address

如果從report crash log得到的信息如下:

0 MyDJ 0x001b27d7 MyDJ + 1394647

1 MyDJ 0x001b2f05 MyDJ + 1396485

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

2、起始地址:即使每次iOS app啟動都會加載(main module)主模塊在不同的內(nèi)存地址,但是dSYM文件假設你的main module加載在地址0x1000(大多數(shù)情況是這個,也有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)

看到?jīng)]?同樣解析出來了。


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

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)

看到?jīng)],其實跟第一種情況解析出來的結果是一致的。
----------------------------------------------------
第三種方法其實比較常用,因為這種情況對于系統(tǒng)庫一樣適用,如有以下日志(是從一個完整的 *.crash日志里面取出來的一條記錄):
6   Foundation                    0x302ff692 0x302f4000 + 46738
這個經(jīng)過計算后 -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


經(jīng)過對比,兩種方法解析出來的結果也是一致的。


--------------------------------------------
綜上所述,以上所有情況與方法,最好的當數(shù)第三種了。
以上的方法都需要對應的dSym文件,可以使用如下方法對比是否是匹配
MAC上有個免費的小工具——dwarfdump,可以簡便地檢測出app和相應的dSYM。
使用起來很簡單。分三步即可。
1> 根據(jù)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信息可以被正確地拿到。


向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內(nèi)容。

AI