回顧 crash log 分析

1、 crash log 格式

圖片來源：www.cnblogs.com/ciml/p/7422…

基本信息：

Binary Images ：

大概分三部分吧，一、基本信息二、線程三、Binary Images（二進制文件）

一、基本信息

重點看：

一、 CodeType: Arm-64

二、Exception Type:崩潰類型

三、Triggered by Thread: 1 崩潰的是哪一個線程，那麼線程就能夠重點看對應的 thread 就行了。

二、線程

主要四列

第一列：調用堆棧序號 第二列：二進制包名 第三列：二進制運行時的地址 第四列： 二進制的基地址加偏移量（偏移量是十進制，計算時要轉爲16進制）

計算規則：運行時地址 = 起始地址 + 偏移量（轉爲16進制）

每一個二進制包的起始地址是不同的，在 crash log 底部會列出全部的二進制包的名字，路徑和 起始地址和結束地址

正常狀況下根據 本身的 app 的起始地址，能夠經過 atos 和 dSYM 文件，算出對應的代碼是什麼。

atos

atos 命令的參數：

-arch : 對應的就是Code Type，`Arm-64`對應的就是 arm64。 
-o : 二進制路徑
-l : 運行時內存地址
複製代碼

能夠參考下面的圖片：

atos -arch arm64 -o TheElements.app.dSYM/Contents/Resources/DWARF/TheElements -l 0x1000e4000 0x00000001000effdc

算出結果：
-[AtomicElementViewController myTransitionDidStop:finished:context:]
複製代碼

atos 後面的-l參數能夠跟好幾個地址，解析出對應的堆棧，可是第一個應該是基地址，例如：

atos -o ***.ipa.dSYM/Contents/Resources/DWARF/*** -arch arm64 -l 0x102fa8000 0x0000000103c2cd7c 0x0000000103bff898 0x0000000103bfd438

輸出：
-[BLYCrashManager didCrashAccidentHappened] (in ***) + 204
BLYCrashHandlerCallback (in ***) + 432
BLYBSDSignalHandlerCallback (in ***) + 92
複製代碼

附上 Code Type 可能的值：

其中arm64是指架構類型，這個就須要根據APP是在哪一個手機上運行決定的，這裏有個型號對應表 armv6：iPhone、iPhone二、iPhone3G armv7：iPhone四、iPhone4S armv7s：iPhone五、iPhone5C arm64：iPhone5S

三、Binary Images

0x100004000 - 0x10000ffff CrashTest arm64  <5fc8820b297631d087e5e665b261ed0c> /var/mobile/Containers/Bundle/Application/D8F09771-5B65-4403-A19C-CE77DAF32623/CrashTest.app/CrashTest

0x120070000 - 0x120097fff dyld arm64  <f958ba064181388a9658f927da42e9e7> /usr/lib/dyld
複製代碼

分爲5列：

第1列： 地址區間 ，二進制文件運行時 其實地址（基址）和結束地址

第2列：二進制包名，app 的名字，動態連接庫等等

第3列：二進制 架構類型： arm64

第4列：UUID

第5列：二進制路徑

2、symbolicatecrash

xcode 提供的一個命令，能夠符號化 crash log。 這個腳本的地址在：

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
複製代碼

能夠拷貝到 usr/local/bin目錄下，這樣就能夠全局使用了，不用每次都輸入那麼一長串。

cp /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash /usr/local/bin
複製代碼

把 crash.log 和 dSYM 文件拷貝到一個目錄下面執行：

symbolicatecrash ***.crash ***.dSYM > ***_symbol.crash
複製代碼

執行若是報錯：

Error: "DEVELOPER_DIR" is not defined at /usr/local/bin/symbolicatecrash line 69.
複製代碼

則須要執行：

export DEVELOPER_DIR="/Applications/XCode.app/Contents/Developer"
複製代碼

若是執行成功，就能夠在當前目錄獲得符號化的 crashlog 了

3、slide address

ASLR 技術Address space layout randomization,ASLR經過將系統可執行程序隨機裝載到內存裏，從而防止緩衝區溢出攻擊 因爲 ASLR 的緣故，致使 程序crash後生成的crash log 中的 stack address 與 對應的 symbol address 不一致，有一個偏移量 slide，slide是程序裝在時隨機生成的隨機數。 很簡單 symble address ＝ stack address －slide；

引入新的概念：

stack address ： 程序運行時線程棧中 全部 函數調用的地址

symble address ： dsym文件中函數符號對應的地址，用此地址 在 dsym 文件中能夠 查出對應的 符號信息。 無 ASLR 機制時 stack address 等於symble address 。

slide address 獲取代碼：

/** 獲取加載偏移地址 */
long long getSlide()
{
    long long slide = 0;
    for (uint32_t i = 0; i < _dyld_image_count(); i++) {
        if (_dyld_get_image_header(i)->filetype == MH_EXECUTE) {
            slide = _dyld_get_image_vmaddr_slide(i);
            break;
        }
    }
    return slide;
}
複製代碼

atos 和 symbolicatecrash 不須要獲取 Slide Address，只要知道運行時地址就能夠符號化。使用最爲簡單方便。

還有其餘工具如：lldb 和 Dwarfdump 就須要複雜點的計算了。

由於它們採用文件地址（0x10000ECC4），所以您須要考慮爲這些工具設置偏移量。 從 dSYM 獲取偏移量的一種方法是使用「otool」，它能夠與 OSX 上的 XCode 開發人員工具一塊兒使用。

您須要查找 LC_SEGMENT_64（arm64）或 LC_SEGMENT（armv7，armv7s）段和「vmaddr」條目。 對於iOS，對於32位一般爲0x4000，對於64位架構一般爲0x100000000。

otool -l ApteligentExampleApp.dSYM > ApteligentExampleApp.otool.output

Load command 3
cmd LC_SEGMENT_64
cmdsize 1032
segname __TEXT
vmaddr 0x0000000100000000
複製代碼

最後

參考連接：

www.cnblogs.com/feng9exe/p/…

www.cnblogs.com/feng9exe/p/…

www.cnblogs.com/ciml/p/7422…

www.jianshu.com/p/035d9e863…

www.jianshu.com/p/0a1c029e9…

www.jianshu.com/p/e66fc953a…

foggry.com/blog/2015/0…

developer.apple.com/library/arc…

www.xuyanlan.com/2019/01/14/…