神说要有光，于是世界有了光。老板说要没bug，臣妾真的做不到啊。
不过亡羊补牢为时不晚，用市面上几种错误统计SDK都可以收集到bug信息，可是有些问题难以解读，怎么才能转换为可读的错误信息呢？
首先我们举一个难以解读bug信息为例
Application received signal SIGSEGV
(null)
((
0 CoreFoundation 0x000000018f6441d8 <redacted> + 148
1 libobjc.A.dylib 0x000000018e07c55c objc_exception_throw + 56
2 CoreFoundation 0x000000018f644108 <redacted> + 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 <redacted> + 24
8 libdispatch.dylib 0x000000018e4cd1c0 <redacted> + 16
9 libdispatch.dylib 0x000000018e4d1d6c _dispatch_main_queue_callback_4CF + 1000
10 CoreFoundation 0x000000018f5f1f2c <redacted> + 12
11 CoreFoundation 0x000000018f5efb18 <redacted> + 1660
12 CoreFoundation 0x000000018f51e048 CFRunLoopRunSpecific + 444
13 GraphicsServices 0x0000000190fa1198 GSEventRunModal + 180
14 UIKit 0x00000001954f8628 <redacted> + 684
15 UIKit 0x00000001954f3360 UIApplicationMain + 208
16 xxx_iOSClient 0x10002856c xxx_iOSClient + 165228
17 libdyld.dylib 0x000000018e5005b8 <redacted> + 4
)
dSYM UUID: EBD1C5FD-341F-XXXX-B440-21029AA4421D
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: Ping2_iOSClient
Base Address: 0x0000000100060000
我们可以看到这是一个野指针的错误，异常指向了某一块内存地址。
但是，这块内存地址所对应的文件名和其他信息并没法直接查看，那怎么定位问题呢？
那么我们先解释几个概念：
什么是符号表？
符号表是内存地址与函数名、文件名、行号的映射表。符号表元素如下所示：
<起始地址> <结束地址> <函数> [<文件名:行号>]
<p></p>
为什么要配置符号表？
为了能快速并准确地定位用户APP发生Crash的代码位置，使用符号表对APP发生Crash的程序堆栈进行解析和还原。
举一个例子：
栗子
<p></p>
使用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
右键文件显示包内容->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上传符号表的方式来完成类似效果：
