iOS crash log 解析

iOS开发中，经常遇到App在开发及测试时不会有问题，但是装在别人的设备中会出现各种不定时的莫名的 crash，因为iOS设备会保存应用的大部分的 crash Log，所以可以通过 crash Log 来定位 crash 原因。

一. 获取iOS设备上的 crash log

1. 将iOS设备连接到电脑上，打开 Xcode -> Organizer -> Devices,找到该台设备，在 Device logs 中找到 crash log（后缀为 .crash 的 log 文件），将其导出即可。

2. 如果你的应用已经上架App Store，那么开发者可以通过iTunes Connect（Manage Your Applications - View Details - Crash Reports）获取用户的crash log。不过这并不是100%有效的，而且大多数开发者并不依赖于此，因为这需要用户设备同意上传相关信息，详情可参见iOS: Providing Apple with diagnostics and usage information摘要。

二. 解析iOS crash log

获取到的 crash log 中的相关信息都是 16 进制的内存地址，并不能定位崩溃的代码，所以需要将 16 进制的内存地址解析为对应的类及方法。

解析 crash log 需要使用上传应用时所发送的 .app 及 .sYSM 两个文件（所以每次上传新版本时都要保存这两个文件，不然没法解析 crash log），可以将 .app .dYSM 及crash log文件拷贝到同一个文件夹下，使用 Symbolicatecrash 进行解析。

获取 .app 及 .dYSM 文件：在iOS开发中，需要使用Xcode打包生成 .xcarchiver 文件，可以在Xcode - > Organizer - > archive 中进行管理并导出相应的 .xcarchiver 文件，.xcarchiver 文件中就包含 .app 及 .dYSM 文件。

Symbolicatecrash 是一个隐藏文件，并且独立于Xcode，位置在：/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

在利用 Symbolicatecrash 进行解析之前，要检查 .app .dYSM 及 crash log 三个文件的uuid是否一样，只有三者都一样才能进行解析。查看三个文件的 uuid 方法如下：

1. 查看xx.app文件的uuid的方法,在 terminal.app 中输入：

$ dwarfdump --uuid xxx.app/xxx (xxx工程名)

2. 查看xx.app.dSYM文件的uuid的方法，在命令行输入：

$ dwarfdump --uuid xxx.app.dSYM (xxx工程名)

3. 查看 crash log 文件的 uuid的方法：

在 crash log 文件中，找到 Binary Images: 项目名后面第一个尖括号中的一串码就是改 crash log 文件的 uuid。

利用 Symbolicatecrash 进行解析：

在 terminal.app 中输入如下命令：

$ ./symbolicatecrash xxx.crash xxx.app.dSYM > test.log

该命令会将 crash 文件解析成 test.log 文件，test.log 就是可读的函数文件。

输入上述命令可能会出现Error: "DEVELOPER_DIR" is not defined at ./symbolicatecrash line 53.这个错误。

如果出现上述错误，输入命令：export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer，

然后继续执行./symbolicatecrash xxx.crash xxx.app.dSYM > test.log可以成功

三. 其他解析（根据地址解析）：

解析某一个地址的内容

方法一：

$ xcrun atos -o xxx.app/xxx -arch armv7 0x38ad42f9 0x38ad42f9 0x38ad42f9(多个16进制地址，使用空格分开)

方法二：

$ dwarfdump -–lookup 0x000036d2 -–arch armv6 xxx.app.dSYM

如果根据以上两个方法操作，均提示找不到地址的话，可以使用方法三：

方法三：

查找以下内容所对应的地址：

（当前代码行地址 ＝ 当前地址 ＋ 地址偏移量，地址偏移量为十进制数值）

10  TestTransform                    0x00057132 0x4f000 + 33074

1. 先说第一种比较简单的方法利用 "当前地址" 和 "当前代码行地址"

$ xcrun atos -o TestTransform.app/TestTransform -arch armv7 0x3d000 0x0004fc5c

//输出结果：

bddeMacBook-Pro:1 baidu$ xcrun atos -o /Users/baidu/Desktop/1/TestTransform.app/TestTransform -l 0x3d000 0x0004fc5c

got symbolicator for /Users/baidu/Desktop/1/TestTransform.app/TestTransform, base address 4000

main (in TestTransform) (main.m:16)

2. 第二种相对复杂一点，涉及到地址的偏移，首先查看起始地址，即使每次iOS app启动都会加载(main module)主模块在不同的内存地址，但是dSYM文件假设你的main module加载在地址0x1000（大多数情况是这个，也有0x4000的）。

获取此地址的方法：

$ otool -arch armv7 -l /Users/cnstar-tech/crash/xxx.app/xxx  | grep -B 1 -A 10 "LC_SEGM" | grep -B 3 -A 8 "__TEXT"

调用以上方法返回结果如下：

Load command 1

cmd LC_SEGMENT

cmdsize 600

segname __TEXT

vmaddr 0x00004000

vmsize 0x00014000

fileoff 0

filesize 81920

maxprot 0x00000005

initprot 0x00000005

nsects 8

flags 0x0

看到vmaddr显示为0x00004000。

然后查看 　"TestTransform 0x00057132 0x4f000 + 33074"  使用 起始地址＋地址偏移量如：

0x4000 ＋ 33074 ＝ 0xc132   (注意：前面为前面为16进制后面为10进制相加，要都转换成10进制相加，把得出的结果转换成16进制)

就可以使用 "0xc132" 地址查看内容了：

//方法一：

$ dwarfdump --lookup 0xc132 --arch armv7 TestTransform.app.DSYM

//输出结果:

----------------------------------------------------------------------

File: TestTransform.app.DSYM/Contents/Resources/DWARF/TestTransform (armv7)

----------------------------------------------------------------------

Looking up address: 0x000000000000c132 in .debug_info... found!

0x00003947: Compile Unit: length = 0x00007b6e  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x04  (next CU at 0x0000b4b9)

0x00003952: TAG_compile_unit [1] *

AT_producer( "Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)" )

AT_language( DW_LANG_ObjC )

AT_name( "/Users/baidu/Desktop/TestTransform/TestTransform/ViewController.m" )

AT_low_pc( 0x0000a950 )

AT_stmt_list( 0x0000089f )

AT_comp_dir( "/Users/baidu/Desktop/TestTransform" )

AT_APPLE_major_runtime_vers( 0x02 )

0x00003c22:    TAG_subprogram [39] *

AT_name( "__29-[ViewController aaaaaaaaaa:]_block_invoke" )

AT_decl_file( "/Users/baidu/Desktop/TestTransform/TestTransform/ViewController.m" )

AT_decl_line( 191 )

AT_prototyped( 0x01 )

AT_APPLE_isa( 0x01 )

AT_accessibility( DW_ACCESS_public )

AT_low_pc( 0x0000c09c )

AT_high_pc( 0x0000c182 )

AT_frame_base( r7 )

0x00003c46:        TAG_lexical_block [34] *

AT_low_pc( 0x0000c0d6 )

AT_high_pc( 0x0000c17e )

Line table dir : '/Users/baidu/Desktop/TestTransform/TestTransform'

Line table file: 'ViewController.m' line 193, column 0 with start address 0x000000000000c11e

Looking up address: 0x000000000000c132 in .debug_frame... found!

0x00000160: FDE

length: 0x0000000c

CIE_pointer: 0x00000000

start_addr: 0x0000c09c __29-[ViewController aaaaaaaaaa:]_block_invoke

range_size: 0x000000e6 (end_addr = 0x0000c182)

Instructions: 0x0000c09c: CFA=4294967295+4294967295

//方法二：

$ xcrun atos -o /Users/baidu/Desktop/1/TestTransform.app/TestTransform 0xc132

//输出结果：

__29-[ViewController aaaaaaaaaa:]_block_invoke (in TestTransform) (ViewController.m:193)

四. 如何判断两个 crash log 文件的 crash 是同一个原因：

1. 可以先比较 Triggered by Thread 看看是否为同一个线程，不同，则不是同一原因。

2. 如果有 Last Exception Backtrace，可以先比较 Last Exception Backtrace 中地址的行数，行数不同则原因不同，行数如果相同可以将两个 Last Exception Backtrace 中的地址逐个进行比较，（一般最开始几行和最后几行都是调用系统函数，所以地址都是一样的），直到出现第一个不一样的地址，可以用 dwarfdump 分别解析两个地址，如果解析得到的方法不一样，则 crash 原因可不一样。

五. Xcode 中 Organizer 自动解析：

如果项目是在自己机器上打包的，可以将iOS设备连接到电脑上，这样该设备中的 crash log 就会被 Organizer 自动进行解析，如果没有自动解析，可以 右击 crash log 选择 re-symbolicate 进行解析。（之所以 Organizer 可以进行自动解析，是因为在打包的时候会建立 .app 及 .dYSM 两个文件的索引，所以可以自动解析 crash log 文件）

也可以进行手动建立索引，即将该 App 的 .app 及 .dYSM 两个文件拷贝到同一个文件夹中，然后再用 midimport foldername 命令进行手动建立索引，然后，将 crash log 文件导入 Xcode Organizer 中，就会进行自动解析。（可以批量导入 crash log 文件，批量进行解析）

六. 使用专门的 crash log 解析工具进行解析：

比如QuincyKit, Crashlytics, Flurry等。