使用UMeng工具、Terminal或Bugly分析错误日志（iOS）

神说要有光，于是世界有了光。老板说要没bug，臣妾真的做不到啊。

不过亡羊补牢为时不晚，用市面上几种错误统计SDK都可以收集到bug信息，可是有些问题难以解读，怎么才能转换为可读的错误信息呢？

首先我们举一个难以解读bug信息为例

Application received signal SIGSEGV
(null)
((
    0   CoreFoundation                      0x000000018f6441d8  + 148
    1   libobjc.A.dylib                     0x000000018e07c55c objc_exception_throw + 56
    2   CoreFoundation                      0x000000018f644108  + 0
    3   xxx_iOSClient                     0x100374368 xxx_iOSClient + 3621736
    4   xxx_iOSClient                     0x1002dafd0 xxx_iOSClient + 2994128
    5   libsystem_platform.dylib            0x000000018e6d3348 _sigtramp + 52
    6   xxx_iOSClient                     0x100252348 xxx_iOSClient + 2433864
    7   libdispatch.dylib                   0x000000018e4cd200  + 24
    8   libdispatch.dylib                   0x000000018e4cd1c0  + 16
    9   libdispatch.dylib                   0x000000018e4d1d6c _dispatch_main_queue_callback_4CF + 1000
    10  CoreFoundation                      0x000000018f5f1f2c  + 12
    11  CoreFoundation                      0x000000018f5efb18  + 1660
    12  CoreFoundation                      0x000000018f51e048 CFRunLoopRunSpecific + 444
    13  GraphicsServices                    0x0000000190fa1198 GSEventRunModal + 180
    14  UIKit                               0x00000001954f8628  + 684
    15  UIKit                               0x00000001954f3360 UIApplicationMain + 208
    16  xxx_iOSClient                     0x10002856c xxx_iOSClient + 165228
    17  libdyld.dylib                       0x000000018e5005b8  + 4
)
 dSYM UUID: EBD1C5FD-341F-XXXX-B440-21029AA4421D
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: Ping2_iOSClient
Base Address: 0x0000000100060000

我们可以看到这是一个野指针的错误，异常指向了某一块内存地址。
但是，这块内存地址所对应的文件名和其他信息并没法直接查看，那怎么定位问题呢？

那么我们先解释几个概念：

什么是符号表？

符号表是内存地址与函数名、文件名、行号的映射表。符号表元素如下所示：
<起始地址> <结束地址> <函数> [<文件名:行号>]

为什么要配置符号表？

为了能快速并准确地定位用户APP发生Crash的代码位置，使用符号表对APP发生Crash的程序堆栈进行解析和还原。
举一个例子：

栗子

使用UMeng提供的解析工具进行分析

• **下载错误分析工具 **并解压zip得到umcrashtool文件，可将umcrashtool与已下载的xxx.csv文件放入同一目录下。

在UMeng错误列表中点击右上角报表会自动生成.csv文件，前去报表中心下载后放在同一目录即可。

栗子

• 在terminal中运行umcrashtool命令，参数为错误分析的.csv文件绝对路径

    Last login: Mon Feb 20 11:23:25 on ttys005
    bogon:~ Fuhanyu$ cd /Users/Fuhanyu/Desktop/My\ code/UMengCrashReport/
    bogon:UMengCrashReport Fuhanyu$ ./umcrashtool /Users/Fuhanyu/Desktop/My\ code/UMengCrashReport/屏方_错误分析_错误详情_111932.csv 
    Total Crahes 1  
    >---------------------- Row   1 -----------------------<
    => Start Application received signal SIGSEGV 
        -> translating『 0x100374368 』=> 
        -> translating『 0x1002dafd0 』=> 
        -> translating『 0x100252348 』=> __39-[XHLaunchAd startWaitDataDispathTiemr]_block_invoke_2 /Users/Fuhanyu/XXX/XXX/Pods/XHLaunchAd/XHLaunchAd/XHLaunchAd.m: line 460
        -> translating『 0x10002856c 』=> main /Users/Fuhanyu/XXX/XXX/XXX/main.m: line 12
    => End Application received signal SIGSEGV 
    >------------------------------------------------------<
  
    Export to file: /Users/Fuhanyu/Desktop/My code/UMengCrashReport/屏方_错误分析_错误详情_111932-symbol.csv
    bogon:UMengCrashReport Fuhanyu$ 
  

这样我们就可以简单清晰地定位到问题所在的地方了，用的一个第三方出现了问题。

    __39-[XHLaunchAd startWaitDataDispathTiemr]_block_invoke_2 

使用Terminal分析错误日志

• 在Xcode菜单栏中点击Window->Organizer找到出错的版本的构建版本右键Show in Finder

archives导出.png

右键文件显示包内容->dSYMs->xxx.app.dSYM复制到桌面暂存

• 打开Terminal执行cd 到目录下

   cd /Users/Fuhanyu/Desktop/
  

• 可以查看符号表的UUID是否与统计的相同
  dwarfdump --uuid xxx.app.dSYM
  UUID: 123240FB-XXXX-308D-B3C7-E72BD9932E94 (armv7) xxx.app.dSYM/Contents/Resources/DWARF/xxx
  UUID: EBD1C5FD-341F-XXXX-B440-21029AA4421D (arm64) xxx.app.dSYM/Contents/Resources/DWARF/xxx

• 执行查看对比(逐个尝试错误信息中例如:6 xxx_iOSClient 0x100252348 xxx_iOSClient + 2433864的地址0x100252348
  dwarfdump --arch=arm64 --lookup 0x100252348 /Users/Fuhanyu/Desktop/xxx.app.dSYM/Contents/Resources/DWARF/xxx

• 结果显示(注意关键词AT_name,AT_decl_line,AT_decl_file)
  ----------------------------------------------------------------------
  File: /Users/Fuhanyu/Desktop/xxx.app.dSYM/Contents/Resources/DWARF/xxx (arm64)
  ----------------------------------------------------------------------
  Looking up address: 0x0000000100252348 in .debug_info... found!

    0x0031b8ea: Compile Unit: length = 0x00004e3b  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x00320729)
  
    0x0031b8f5: TAG_compile_unit [107] *
                 AT_producer( "Apple LLVM version 8.0.0 (clang-800.0.42.1)" )
                 AT_language( DW_LANG_ObjC )
                 AT_name( "/Users/Fuhanyu/xxx/xxx/Pods/XHLaunchAd/XHLaunchAd/XHLaunchAd.m" )
                 AT_stmt_list( 0x001216d3 )
                 AT_comp_dir( "/Users/Fuhanyu/xxx/xxx/Pods" )
                 AT_APPLE_optimized( 0x01 )
                 AT_APPLE_major_runtime_vers( 0x02 )
                 AT_low_pc( 0x000000010024ff1c )
                 AT_high_pc( 0x0000000100253320 )
  
    0x0031f0a9:     TAG_subprogram [159] *
                     AT_low_pc( 0x0000000100252314 )
                     AT_high_pc( 0x0000000100252378 )
                     AT_frame_base( reg29 )
                     AT_name( "__39-[XHLaunchAd startWaitDataDispathTiemr]_block_invoke_2" )
                     AT_decl_file( "/Users/Fuhanyu/xxx/xxx/Pods/XHLaunchAd/XHLaunchAd/XHLaunchAd.m" )
                     AT_decl_line( 460 )
                     AT_prototyped( 0x01 )
                     AT_APPLE_optimized( 0x01 )
    Line table dir : '/Users/Fuhanyu/xxx/xxx/Pods/XHLaunchAd/XHLaunchAd'
    Line table file: 'XHLaunchAd.m' line 465, column 18 with start address 0x0000000100252348
  
    Looking up address: 0x0000000100252348 in .debug_frame... not found.
  

使用Bugly配置符号表

Bugly提供了两种符号表上传方式，分别是自动上传和手动上传，可直接参考文档：Bugly iOS 符号表配置

使用集成使用Bugly的朋友可以参考Bugly上传符号表的方式来完成类似效果：

bugly效果

---

参考：UMeng错误分析iOS功能说明
   解析iOS崩溃日志(crash Log)