前言
随着APP用户增多，线上bug的跟踪和修复就显得尤为重要。市面上常用的日志收集工具有友盟、bugly、fabric等。前段时间发现项目中线上bug增多，开始关注统计的Crash日志。
示例Crash
Application received signal SIGSEGV
(null)
((
0 CoreFoundation 0x0000000181ee82f4 <redacted> + 160
1 libobjc.A.dylib 0x000000019370c0e4 objc_exception_throw + 60
2 CoreFoundation 0x0000000181ee8218 <redacted> + 0
3 appname 0x1002a07f4 appname + 2754548
4 libsystem_platform.dylib 0x0000000193f3894c _sigtramp + 52
5 appname 0x1001b4e7c appname + 1789564
6 UIKit 0x0000000186c07bbc <redacted> + 72
7 UIKit 0x0000000186944db4 <redacted> + 500
8 UIKit 0x0000000186a00d68 <redacted> + 380
9 UIKit 0x0000000186946a08 <redacted> + 100
10 UIKit 0x0000000186924d44 <redacted> + 704
11 UIKit 0x00000001869243dc <redacted> + 144
12 UIKit 0x00000001869242bc <redacted> + 484
13 UIKit 0x0000000186922e54 <redacted> + 524
14 UIKit 0x0000000186925c20 <redacted> + 440
15 UIKit 0x0000000186b1e038 <redacted> + 1100
16 UIKit 0x000000018697de28 <redacted> + 88
17 Foundation 0x0000000182ddc180 __NSFireDelayedPerform + 424
18 CoreFoundation 0x0000000181ea012c <redacted> + 28
19 CoreFoundation 0x0000000181e9fddc <redacted> + 888
20 CoreFoundation 0x0000000181e9d828 <redacted> + 1372
21 CoreFoundation 0x0000000181dc92d4 CFRunLoopRunSpecific + 396
22 GraphicsServices 0x000000018b5df6fc GSEventRunModal + 168
23 UIKit 0x000000018698efac UIApplicationMain + 1488
24 appname 0x1000adbec appname + 711660
25 libdyld.dylib 0x0000000193d8aa08 <redacted> + 4
)
dSYM UUID: C2FB2F08-1865-3556-A836-CCA510A6EEF8
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: appname
Base Address: 0x0000000100014000
SIGSEGV和SIGBUS一般是因为访问已被释放的内存或者调用不存在的方法导致的。从Crash Log中找到下面这句，它指出了应用名称，崩溃时的调用方法的地址，文件的地址以及方法所在的行的位置。
5 appname 0x1001b4e7c appname + 1789564
分析Crash准备
一、 找到打包程序的DYSM文件
DYSM文件通常在.xcarchive文件中。 打开Xcode window->Organizer，选中Archives，可看到archive文件。然后Show in Finder->显示包内容，一直往下找，路径如下
/Users/username/Library/Developer/Xcode/Archives/2017-01-03/ appname\ 17-1-3\ 下午5.58.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF
注意里面的username 和 appname 是你自己的。
二、 验证环节
用dwarfdump来检测crash log中dSYM UUID和本地的dSYM文件是否匹配。
打开终端：
cd /Users/username/Library/Developer/Xcode/Archives/2017-01-03/ appname\ 17-1-3\ 下午5.58.xcarchive/dSYMs
//输入命令
dwarfdump --uuid appname.app.dSYM
获得结果如下
UUID: 43DFAD01-B92C-3DFA-8189-F72EC9D5FC32 (armv7) appname.app.dSYM/Contents/Resources/DWARF/appname
UUID: C2FB2F08-1865-3556-A836-CCA510A6EEF8 (arm64) appname.app.dSYM/Contents/Resources/DWARF/appname
Crash log中的dSYM UUID与本地的dYSM文件是相匹配的，就可以下一步了。
分析Crash
1、常用姿势
打开终端，执行下面命令
cd /Users/username/Library/Developer/Xcode/Archives/2017-01-03/ appname\ 17-1-3\ 下午5.58.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF
执行命令行 arm64【CPU Type】
atos -arch arm64 -o appname 0x1001b4e7c
获得结果如下
-[CWGuideViewController scrollViewDidScroll:] (in appname) (CWGuideViewController.m:91)
2、特殊姿势
打开终端，执行下面命令
cd /Users/username/Library/Developer/Xcode/Archives/2017-01-03/ appname\ 17-1-3\ 下午5.58.xcarchive/dSYMs
//输入命令行
dwarfdump --arch=arm64 --lookup 0x1001b4e7c /Users/username/Library/Developer/Xcode/Archives/2017-01-03/appname\ 17-1-3\ 下午6.19.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname
获得结果如下
----------------------------------------------------------------------
File: /Users/zhangbo/Library/Developer/Xcode/Archives/2017-01-03/appname 17-1-3 下午6.19.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname (arm64)
----------------------------------------------------------------------
Looking up address: 0x00000001001b4e7c in .debug_info... found!
0x002fc040: Compile Unit: length = 0x000024fe version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x002fe542)
0x002fc04b: TAG_compile_unit [1] *
AT_producer( "Apple LLVM version 7.3.0 (clang-703.0.31)" )
AT_language( DW_LANG_ObjC )
AT_name( "/Users/zhangbo/Desktop/QGroup/project/New appname/appname/appname/appname/Application/LaunchVC/CWGuideViewController.m" )
AT_stmt_list( 0x0011e21b )
AT_comp_dir( "/Users/zhangbo/Desktop/QGroup/project/New appname/appname/appname" )
AT_APPLE_optimized( 0x01 )
AT_APPLE_major_runtime_vers( 0x02 )
AT_low_pc( 0x00000001001b456c )
AT_high_pc( 0x00000001001b5010 )
0x002fe369: TAG_subprogram [38] *
AT_low_pc( 0x00000001001b4d9c )
AT_high_pc( 0x00000001001b4fbc )
AT_frame_base( reg29 )
AT_object_pointer( {0x002fe388} )
AT_name( "-[CWGuideViewController scrollViewDidScroll:]" )
AT_decl_file( "/Users/zhangbo/Desktop/QGroup/project/New appname/appname/appname/appname/Application/LaunchVC/CWGuideViewController.m" )
AT_decl_line( 87 )
AT_prototyped( 0x01 )
AT_APPLE_optimized( 0x01 )
Line table dir : '/Users/zhangbo/Desktop/QGroup/project/New appname/appname/appname/appname/Application/LaunchVC'
Line table file: 'CWGuideViewController.m' line 91, column 9 with start address 0x00000001001b4e7c
Looking up address: 0x00000001001b4e7c in .debug_frame... not found.
观察结果里面的这几项AT_name、Line table dir :、Line table file:，就可以定位到Crash位置了。
至此，bug就定位到具体源码了，希望所有的同学都能完美解决自己的bug。
总结
现在市面上大部分的APP使用的都是友盟统计，我发现友盟统计Crash有一个问题，部分Crash日志通过上面的方法解析不出来。翻阅了一下友盟的更新日志，貌似还没有修复这个问题。建议更换一个Crash统计工具。
