iOS 线上Crash分析姿势

前言

随着APP用户增多，线上bug的跟踪和修复就显得尤为重要。市面上常用的日志收集工具有友盟、bugly、fabric等。前段时间发现项目中线上bug增多，开始关注统计的Crash日志。

示例Crash

Application received signal SIGSEGV
(null)
((
    0   CoreFoundation                      0x0000000181ee82f4  + 160
    1   libobjc.A.dylib                     0x000000019370c0e4 objc_exception_throw + 60
    2   CoreFoundation                      0x0000000181ee8218  + 0
    3   appname                        0x1002a07f4 appname + 2754548
    4   libsystem_platform.dylib            0x0000000193f3894c _sigtramp + 52
    5   appname                        0x1001b4e7c appname + 1789564
    6   UIKit                               0x0000000186c07bbc  + 72
    7   UIKit                               0x0000000186944db4  + 500
    8   UIKit                               0x0000000186a00d68  + 380
    9   UIKit                               0x0000000186946a08  + 100
    10  UIKit                               0x0000000186924d44  + 704
    11  UIKit                               0x00000001869243dc  + 144
    12  UIKit                               0x00000001869242bc  + 484
    13  UIKit                               0x0000000186922e54  + 524
    14  UIKit                               0x0000000186925c20  + 440
    15  UIKit                               0x0000000186b1e038  + 1100
    16  UIKit                               0x000000018697de28  + 88
    17  Foundation                          0x0000000182ddc180 __NSFireDelayedPerform + 424
    18  CoreFoundation                      0x0000000181ea012c  + 28
    19  CoreFoundation                      0x0000000181e9fddc  + 888
    20  CoreFoundation                      0x0000000181e9d828  + 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  + 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统计工具。