macOS 應(yīng)用的崩潰日志解析

一、獲取崩潰日志對(duì)應(yīng)的.dSYM文件

Xcode-->Window-->Organizer 找到對(duì)應(yīng)的 .xcarchive 文件 -->Show in Finder 找到對(duì)應(yīng)的.dsym

二、獲取Xcode 下面的symbolicatecrash工具

復(fù)制下面的路徑前往獲取symbolicatecrash

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

三、創(chuàng)建新的文件夾將.dSYM、symbolicatecrash、崩潰日志文件.txt 三個(gè)文件放入。這里文件夾命名crash

四、使用終端命令進(jìn)入到剛剛創(chuàng)建的crash文件夾并執(zhí)行命令行

 cd /Users/peanut/Desktop/crash 

 ./symbolicatecrash ./crashLog.txt ./M1 Controller.app.dSYM > MyAppCrash.log

symbolicatecrash:是符號(hào)化工具
crashLog.txt:是崩潰日志的文件名
My Controller.app.dSYM:是dSYM 的名稱。（注意：我這里的文件名是有空格的。下文會(huì)提及并解釋）
MyAppCrash.log:是符號(hào)化后導(dǎo)出的文件

五、執(zhí)行終端命令后出現(xiàn)Error: "DEVELOPER_DIR" is not defined at ./symbolicatecrash line 69.

那是因?yàn)闆](méi)有定義文件地址.繼續(xù)執(zhí)行

export DEVELOPER_DIR="/Applications/XCode.app/Contents/Developer"

-命令后 再次執(zhí)行

./symbolicatecrash ./crashLog.txt ./M1 Controller.app.dSYM > MyAppCrash.log

即可 出現(xiàn)MyAppCrash.log文件。

???? 如果解析的是iOS App的崩潰日志到這里可能沒(méi)啥問(wèn)題。到此解決問(wèn)題！
????如果解析的是macOS 應(yīng)用的崩潰日志，有可能會(huì)收到如錯(cuò)誤提示。如果沒(méi)有出現(xiàn)錯(cuò)誤提示，則解析成功！
Unsupported crash log version: 12 at ./symbolicatecrash line 616.

peanut@huashengkedeMacBook-Pro ~ % cd /Users/peanut/Desktop/crash 
peanut@huashengkedeMacBook-Pro crash % ./symbolicatecrash ./crashLog.txt ./My Controller.app.dSYM > MyAppCrash.log
Error: "DEVELOPER_DIR" is not defined at ./symbolicatecrash line 69.
peanut@huashengkedeMacBook-Pro crash % export DEVELOPER_DIR="/Applications/XCode.app/Contents/Developer"           
peanut@huashengkedeMacBook-Pro crash % ./symbolicatecrash ./crashLog.txt ./My Controller.app.dSYM > MyAppCrash.log
Unsupported crash log version: 12 at ./symbolicatecrash line 616.

翻閱資料發(fā)現(xiàn)xcode 還不支持導(dǎo)入 OSX 崩潰日志并將其符號(hào)化，參考資料。

所以為了解析macOS崩潰日志 ，我們需要使用到atos 命令

六、繼以上步驟繼續(xù)往下解析macOS崩潰日志

1.獲取.dYSM的UUID
執(zhí)行命令xcrun dwarfdump --uuid name.app.dSYM

peanut@huashengkedeMacBook-Pro crash % xcrun dwarfdump --uuid My controller.app.dSYM        
error: My: No such file or directory

可以看到我替換了name.app.dSYM的名稱My Controller.app.dSYM后執(zhí)行出錯(cuò)。是因?yàn)槲业拿Q中帶了空格。在這里我們可以將crash文件夾里面的My Controller.app.dSYM修改為MyController.app.dSYM這里修改名稱并不會(huì)對(duì)符號(hào)化有任何影響請(qǐng)放心～
我們?cè)俅螆?zhí)行

peanut@huashengkedeMacBook-Pro crash % xcrun dwarfdump --uuid MyController.app.dSYM
UUID: 28409CBF-FF6E-3035-AA0D-2C622D947194 (x86_64) MyController.app.dSYM/Contents/Resources/DWARF/My Controller
UUID: 1F606971-BC0F-385E-872D-1A159905FF03 (arm64) MyController.app.dSYM/Contents/Resources/DWARF/My Controller

在這里獲取到了倆個(gè)UUID，對(duì)于這里我也沒(méi)有理解其含義。有知道的小伙伴可以解釋下。
2.在崩潰日志中Binary Images二進(jìn)制圖像部分找到您的應(yīng)用
使用第一步獲取到的UUID分別在崩潰日志中查找。
我只找到arm64對(duì)應(yīng)的UUID ，另一個(gè)x86_64沒(méi)有找到

Binary Images:
       0x1191e8000 -        0x11931ffff com.apple.audio.units.Components (1.14) <fd93a3bc-5142-33ea-88bd-c2258c5a032d> /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio
       0x104f90000 -        0x104f9bfff com.apple.iokit.IOUSBLib (900.4.2) <351e046e-b6eb-3ee7-96b3-841918c05405> /System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/IOUSBLib.bundle/Contents/MacOS/IOUSBLib
       0x1046c8000 -        0x1046d3fff libobjc-trampolines.dylib (*) <9381bd6d-84a5-3c72-b3b8-88428afa4782> /usr/lib/libobjc-trampolines.dylib
       0x1048d8000 -        0x1048e7fff org.cocoapods.SnapKit (5.0.1) <fa297fb0-0071-3417-bf2c-b0cdba7dade8> /Applications/My Controller.app/Contents/Frameworks/SnapKit.framework/Versions/A/SnapKit
       0x1042f0000 -        0x104397fff com.cn.******.my (1.0) <1f606971-bc0f-385e-872d-1a159905ff03> /Applications/My Controller.app/Contents/MacOS/My Controller
       0x1894a0000 -        0x189978fff com.apple.CoreFoundation (6.9) <84b539d5-22c9-3f8c-84c8-903e9c7b8d29> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
       0x18a5f5000 -        0x18b252fff com.apple.Foundation (6.9) <99e0292d-7873-3968-9c9c-5955638689a5> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
       0x18cd42000 -        0x18e07efff com.apple.AppKit (6.9) <61f710be-9132-3cc2-883d-066365fba1ad> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
       0x190531000 -        0x1905a4ff7 com.apple.AE (944) <3b96540c-5db5-3880-bc50-a759b87f6638> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
       0x193c8d000 -        0x193f50fff com.apple.HIToolbox (2.1.1) <7db6c397-563f-3756-908c-e25b019a1848> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
       0x1890b0000 -        0x189138a17 dyld (*) <37bbc384-0755-31c7-a808-0ed49e44dd8e> /usr/lib/dyld
               0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
       0x199108000 -        0x199665fff libswiftCore.dylib (*) <c2fd0f69-d72c-37a5-938e-1bd710c88431> /usr/lib/swift/libswiftCore.dylib
       0x189438000 -        0x189444fff libsystem_pthread.dylib (*) <386b0fc1-7873-3328-8e71-43269fd1b2c7> /usr/lib/system/libsystem_pthread.dylib
       0x1893fd000 -        0x189437ffb libsystem_kernel.dylib (*) <9b8b53f9-e2b6-36df-98e9-28d8fca732f2> /usr/lib/system/libsystem_kernel.dylib
       0x1939b5000 -        0x1939defff com.apple.audio.caulk (1.0) <f2da6e2e-b5a0-3ce7-97f5-7d2141a3ec32> /System/Library/PrivateFrameworks/caulk.framework/Versions/A/caulk
       0x18bac2000 -        0x18c1c8fff com.apple.audio.CoreAudio (5.0) <e818958c-f2dc-37df-9896-ad6e9bcd028a> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio

查找到的我的應(yīng)用信息如下

0x1042f0000 -        0x104397fff com.cn.******.my (1.0) <1f606971-bc0f-385e-872d-1a159905ff03> /Applications/My Controller.app/Contents/MacOS/My Controller

尖括號(hào)中的部分是 UUID... 驗(yàn)證它是否與 dwarfdump 的輸出匹配。如果不匹配，則說(shuō)明您查看的是錯(cuò)誤的版本。版本號(hào)在括號(hào)中 - 這可能有助于您找到正確的版本。
注：如果你確定崩潰日志與.dSYM版本是一致的話 ?？梢院雎?步驟。直接在Binary Images中查找到自己應(yīng)用的bundle id 即可

3.在Binary Images部分找到您的應(yīng)用加載地址。在上面的例子中，加載地址是0x1042f0000。

4.在崩潰日志中找到應(yīng)用程序崩潰的位置


Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000001, 0x0000000104300724

Termination Reason:    Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process:   exc handler [5840]

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   My Controller                          0x104300724 0x1042f0000 + 67364
1   My Controller                          0x1042fc9d4 0x1042f0000 + 51668
2   My Controller                          0x1042fc724 0x1042f0000 + 50980
3   My Controller                          0x1042fc774 0x1042f0000 + 51060
4   My Controller                          0x104344a74 0x1042f0000 + 346740
5   My Controller                          0x1043468fc 0x1042f0000 + 354556
6   My Controller                          0x104345d5c 0x1042f0000 + 351580
7   My Controller                          0x104346120 0x1042f0000 + 352544
8   CoreFoundation                         0x189513144 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148
9   CoreFoundation                         0x1895a73d8 ___CFXRegistrationPost_block_invoke + 88
10  CoreFoundation                         0x1895a7320 _CFXRegistrationPost + 440

可以看到0x104300724 可能就是程序崩潰的地址
5.運(yùn)行 atos 以獲取有關(guān)該地址的信息
1步驟中我們獲取到二個(gè)UUID分別對(duì)應(yīng)arm64、x86_64。這這里我們是用 arm64的那個(gè)UUID獲取到應(yīng)用信息的。故命令行中使用arm64 ，反之則使用x86_64

atos -o MyController.app.dSYM -arch arm64 -l 0x1042f0000 0x104300724

可以看到符號(hào)化后的輸出

specialized MainContainView.recoverLastBuildUI() (in My Controller) (MainContainView.swift:101)

輸出表明是在MainContainView中的recoverLastBuildUI()方法出現(xiàn)了崩潰 具體在101行。到此解析結(jié)束

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容