iOS 手动解析bugly上的crash信息

1、找到和crash日志对应的符号表文件（UUID匹配）

• 查看crash日志里的UUID
  

  UUID
  也可以在其他信息里查看
  UUID

• 在mac上查找某个UUID对应的dSYM文件

mdfind "com_apple_xcode_dsym_uuids == <UUID>"
// 使用mdfind时，UUID需要格式转换（增加“-”）： 12345678-1234-1234-1234-xxxxxxxxxxxx
// 例如，要定位的dSYM的UUID为：E30FC309DF7B3C9F8AC57F0F6047D65F 则定位dSYM文件的命令如下:
// mdfind "com_apple_xcode_dsym_uuids == E30FC309-DF7B-3C9F-8AC5-7F0F6047D65F"

• 查看dSYM文件的UUID

dwarfdump --uuid <Path to dSYM file>

2. 计算崩溃符号表地址

• 拿到偏移量

  
  查看偏移量

bugly上的偏移量是10进制表示，计算时需要转换成十六进制，上图中的偏移量十六进制为0xf5b24。

• 获取符号表中的TEXT段起始地址

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

运行结果中的片段如下：

符号表中TEXT段起始地址

• 计算crash在符号表中对应的地址

符号表堆栈地址 = 符号表起始地址 + 偏移量

即： 0x0000000100000000 + 0xf5b24 = 0x1000F5B24，接下来就可以根据这个地址解析出崩溃位置了。

3. 崩溃信息还原

• 方法一（dwarfdump）：

dwarfdump --arch armv7 Your.app.dSYM --lookup 0x1000F5B24

这里的armv7是运行设备的CPU指令集，而不是二进制文件的指令集
比如armv7指令集的二进制文件运行在arm64指令集的设备上，这个地方应该写arm64。

• 方法二（atos）：

atos -o Your.app.dSYM/Contents/Resources/DWARF/Your -arch armv7 0x1000F5B24

4. 其他

• 还可以使用atos便捷还原崩溃信息，不需要自己计算崩溃对应符号表中的地址

atos -o Your.app.dSYM/Contents/Resources/DWARF/Your -arch armv7 -l 0x0000000102bf4000 0x0000000102ce9b24

其中 -l 选项指定了二进制文件在运行时的起始地址0x0000000102bf4000，后面跟的是崩溃发生的运行时地址0x0000000102ce9b24。

• 运行同crash相同版本代码，根据起始地址+偏移量定位
  如果已经找不到之前的dSYM文件，也可以使用crash版本对应的代码进行本地验证，其中需要注意以下几点：
  • xcode版本需要一样（可以使用不同的mac机器和环境证书）；
  • 编译模式必须要一样；
  • 如果是发生在系统底层代码，至少保证手机系统版本一样，最好使用同一系统版本的同一机型；

// 查看当前程序载入的起始地址
// 不指定名称会列出当前载入所有的库
image list "你的程序名"

// 计算crash发生的地址后进行查找
image lookup -a "当前程序载入的起始地址+crash上偏移量所得出的目标地址"

5.参考

• http://www.cocoachina.com/articles/12806