使用Symbolicatecrash和xcrun atos分析crash log

如果是完整的*.crash log，就使用Symbolicatecrash来解析， 使用方法：

1. 找到Symbolicatecrash文件

Xcode 5.0的之后

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/

（附：Mac系统显示隐藏文件

终端中输入以下命令

显示Mac隐藏文件的命令：defaults write com.apple.finder AppleShowAllFiles -bool true

隐藏Mac隐藏文件的命令：defaults write com.apple.finder AppleShowAllFiles -bool false

输入完回车，重启Finder：左上角的苹果标志-->强制退出-->Finder-->重新启动

）

2. Symbolicatecrash文件独立于Xcode，可以拷出来使用，附件中为Xcode4.5中的Symbolicatecrash文件

3. 命终端中输入命令，命令格式：Symbolicatecrash .crash .dSYM > aa.log

即：Symbolicatecrash + 崩溃日志 + APP对应的.dSYM文件 + > + 输出到的文件

4. 如果提示"DEVELOPER_DIR" is not defined

在终端中输入： export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

///————————————————————

根据UncaughtExceptionHandler report crash log（即不是完整的 *.crash文件的时候，而是自己捕捉到的异常发给服务器以便分析） 的地址解析出对于程序位置的方法：

－、第一种情况：

1、计算symbol address

如果从report crash log得到的信息如下：

0 MyDJ 0x001b27d7 MyDJ + 1394647

1 MyDJ 0x001b2f05 MyDJ + 1396485

symbol address = 1394647(地址偏移量，相对起始地址（下面会介绍如何获取此地址）) ＋ 起始地址

2、起始地址：即使每次iOS app启动都会加载(main module)主模块在不同的内存地址，但是dSYM文件假设你的main module加载在地址0x1000（大多数情况是这个，也有0x4000的）。

获取此地址的方法：The slide value is the value of vmaddr in LC_SEGMENT cmd (Mostly this is 0x1000)

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

Load command 1

     cmd LC_SEGMENT

 cmdsize 736

 segname __TEXT

  vmaddr 0x00004000

  vmsize 0x001ec000

 fileoff 0

filesize 2015232

 maxprot 0x00000005

initprot 0x00000005

  nsects 10

   flags 0x0

“ vmaddr 0x00004000” 此地址便为app运行的起始地址。

1394647 ＋ 0x4000 = 0x1587d7 (symbol address)

3、最后解析此地址：

NapoleonmatoMac-mini:~ cnstar-tech$ xcrun atos -arch armv7 -o /Users/cnstar-tech/crash/MyDJ.app/MyDJ 0x1587d7

+[UncaughtExceptionHandler backtrace] (in MyDJ) (UncaughtExceptionHandler.m:29)

“+[UncaughtExceptionHandler backtrace] (in MyDJ) (UncaughtExceptionHandler.m:29)” 这个便是最后解析结果

二、第二种情况：

如果从crash log得到的对于的信息如下：

7   MyDJ                          0x000896e2 0x19000 + 460514

8   MyDJ                          0x000e5934 0x19000 + 837940

9   MyDJ                          0x000e585e 0x19000 + 837726

这种情况便无需计算symbol address，可以直接使用－load address相对偏移进行解析

命令如下：

NapoleonmatoMac-mini:~ cnstar-tech$ xcrun atos -arch armv7s -o /Users/cnstar-tech/crash/MyDJ.app/MyDJ -l 0x19000 0x000896e2

got symbolicator for /Users/cnstar-tech/crash/MyDJ.app/MyDJ, base address 4000

-[HTTPFetcher startWithUrlString:rangeFrom:to:receiver:action:] (in MyDJ) (HTTPFetcher.m:288)

看到没？同样解析出来了。

下面使用第一种情况的办法进行解析并对比是否一致吧：

460514 ＋ 0x4000 = 0x746e2

NapoleonmatoMac-mini:~ cnstar-tech$ xcrun atos -arch armv7s -o /Users/cnstar-tech/crash/MyDJ.app/MyDJ 0x746e2

-[HTTPFetcher startWithUrlString:rangeFrom:to:receiver:action:] (in MyDJ) (HTTPFetcher.m:288)

可见以上两中解析方法得到的结果是一致的，具体使用哪种就要看具体信息了

三、第三种
如果从report crash log得到的信息如下：
0 MyDJ 0x001b27d7 MyDJ + 1394647
1 MyDJ 0x001b2f05 MyDJ + 1396485
其实这种情况也可以用第二种情况的解析方法，这个时候就需要计算－load address了，计算方法(第一个地址－最后一个地址)：
－load address ＝ 0x001b27d7 － 1394647 ＝ 0x5e000
这时候便可以得到crash log信息如下：
0 MyDJ 0x001b27d7 0x5e000 + 1394647
1 MyDJ 0x001b2f05 0x5e000 + 1396485


这时候使用第二中情况进行解析，结果如下：
NapoleonmatoMac-mini:~ cnstar-tech$ xcrun atos -arch armv7 -o /Users/cnstar-tech/crash/MyDJ.app/MyDJ -l 0x5e000 0x1b27d7
got symbolicator for /Users/cnstar-tech/crash/MyDJ.app/MyDJ, base address 4000
+[UncaughtExceptionHandler backtrace] (in MyDJ) (UncaughtExceptionHandler.m:29)

看到没，其实跟第一种情况解析出来的结果是一致的。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
第三种方法其实比较常用，因为这种情况对于系统库一样适用，如有以下日志（是从一个完整的 *.crash日志里面取出来的一条记录）：
6   Foundation                     0x302ff692 0x302f4000 + 46738
这个经过计算后 －load address ＝ 0x302ff692 － 46738 ＝ 0x302f4000
解析结果如下：
NapoleonmatoMac-mini:~ cnstar-tech$ xcrun atos -arch armv7s -o /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/System/Library/Frameworks/Foundation.framework/Foundation -l 0x302f4000  0x302ff692
got symbolicator for /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/System/Library/Frameworks/Foundation.framework/Foundation, base address 0
-[NSRunLoop(NSRunLoop) runMode:beforeDate:] (in Foundation) + 250
－－－－－－－－－－－－－－－－－－－－－－－－
下面为使用symbolicatecrash解析后的结果：
6   Foundation                     0x302ff692 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 250


经过对比，两种方法解析出来的结果也是一致的。


－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
综上所述，以上所有情况与方法，最好的当数第三种了。

以上的方法都需要对应的dSym文件，可以使用如下方法对比是否是匹配

MAC上有个免费的小工具——dwarfdump，可以简便地检测出app和相应的dSYM。

使用起来很简单。分三步即可。

1> 根据crash log，得到App的UUID。UUID是个字符串，由32个字符组成。得到了UUID，你才能知道是你的哪个版本在用户的iPhone上出了问题。

2> 使用dwarfdump检查app，看哪个app是上面那个UUID。命令行格式：

dwarfdump -u  MyDJ.app/MyDJ

3> 用dwarfdump检查dSYM文件是否是上面的UUID。命令行格式：

dwarfdump -u MyDJ.app.dSYM

如果三者的UUID都是一致的，那么恭喜你，该crash log可以被正确解析出来，stack traces信息可以被正确地拿到。