iOS解析crash日志

• 某崩溃日志其中的几行

5   LSDemo                      0x00000001059ad750 0x10492c000 + 17307472
6   LSDemo                      0x00000001059ad2f4 0x10492c000 + 17306356
7   LSDemo                      0x00000001059b1ac0 0x10492c000 + 17324736

0x00000001059ad750=0x10492c000+17307472 是此函数运行时地址
0x10492c000为运行时此模块基地址
17307472是相对模块基地址,函数偏移量，10进制数需转成16进制

• 可以通过image list 拿到 运行时模块基地址
• 以下列出几个公式

运行时模块基地址 = 静态模块基地址 + ASLR
运行时函数地址 = ASLR + 静态函数地址
运行时函数地址 = 运行时模块基地址 + 函数偏移 
静态函数地址 = 运行时模块基地址 + 函数偏移 - ASLR

静态函数地址 = (静态模块基地址 + ASLR) + 函数偏移 - ASLR
静态函数地址 = 静态模块基地址 + 函数偏移

静态模块基地址 = MACH-O loadCommand  TEXT端中vmaddress值
函数偏移 例如上面第5行崩溃是 +17307472
17307472是10进制需转换成16进制
所以最终寻找的地址是 vmaddress + 17307472 ，然后拿着此值在dsym文件中寻找，
dsym中每个方法或函数对应存储这开始地址和结束地址，当寻找的地址在这2个地址中间，则代表调用的是此方法

• 获取模块静态基地址（即vmaddress值）

otool -l APP_BUNDLE_NAME.app.dSYM/Contents/Resources/DWARF/APP_BUNDLE_NAME

以下4种办法解析crash日志

• 1.dwarfdump

dwarfdump -lookup=静态函数地址  APP_BUNDLE_NAME.app.dSYM

• 2.lldb

target create --arch arm64 ./APP_BUNDLE_NAME.app.dSYM/Contents/Resources/DWARF/APP_BUNDLE_NAME
image lookup --address 静态函数地址 

• 3.atos

atos -arch arm64 -o APP_BUNDLE_NAME.app.dSYM/Contents/Resources/DWARF/APP_BUNDLE_NAME -l 运行时模块基地址 函数运行时地址

• 4.symbolicatecrash也是最常用的
  • 查找到symbolicatecrash目录

  通过find找到symbolicatecrash工具的路径
  find /Applications/Xcode.app -name symbolicatecrash -type f
  

  • 找到symbolicatecrash目录后，进入目录

  ./symbolicatecrash xx.crash xxxx.app.dSYM > symbol.txt
  

• 我自己也封装了个脚本 可以自动判断crash文件和dSYM文件中的UUID是否一致，也可以自动从电脑中查找dSYM文件是否和crash文件的UUID匹配，也可以解析Heaviest stack，使用详见下面链接

https://github.com/lsmakethebest/LSiOSShell