解析友盟crash日志

0x1000ac000最近对项目中添加了crash日志分析，使用到两个分析工具，分别是腾讯的bugly与友盟的错误分析。

开始选择的是bugly，但是在配置时根据文档进行接入，但是一直未显示配置上的成功提醒，咨询技术人员后仍不能解决。因为其他的一些统计使用了友盟，所以就直接打开了友盟的错误日志。

友盟的错误日志经常可以看到的错误信息如下：、

在这种情况下它指出了应用名称，崩溃时的调用方法的地址，文件的地址以及方法所在的行的位置却很难定位问题所在，这个时候就需要mac上的一个工具------dwarfdump，可以简便地检测出app和相应的dSYM。

首先使用用dwarfdump来检测crash log中dSYM UUID和本地的dSYM文件是否匹配。

在终端中使用：

dwarfdump --uuid appName.app.dSYM

UUID: BEBAD9E0-62A7-33F6-9F7B-9D189B521DB7 (armv7) appName.app.dSYM/Contents/Resources/DWARF/appName

UUID: 5578F9FF-9197-3B58-9589-01C4A63A97FB (arm64) appName.app.dSYM/Contents/Resources/DWARF/appName

检查crash log 中的DSYM UUID与本地的DYSM文件是否相匹配。 匹配查询内存地址定位信息

dwarfdump --arch=armv7 --lookup 0x97525  appname.app.dSYM

得到的结果：

----------------------------------------------------------------------

File: appName.app.dSYM/Contents/Resources/DWARF/appName (armv7)

----------------------------------------------------------------------

Looking up address: 0x00000000000f1acf in .debug_info... found!

0x002da508: Compile Unit: length = 0x000051d9version = 0x0002abbr_offset = 0x00000000addr_size = 0x04(next CU at 0x002df6e5)

0x002da513: TAG_compile_unit [1] *

AT_producer( "Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)" )

AT_language( DW_LANG_ObjC )

AT_name( "appName/Classes/Common/*/*.m" )

AT_stmt_list( 0x000d8a76 )

AT_comp_dir( "appName" )

AT_APPLE_optimized( 0x01 )

AT_APPLE_major_runtime_vers( 0x02 )

AT_low_pc( 0x000f1740 )

AT_high_pc( 0x000f38c2 )

0x002db1b6:TAG_subprogram [56] *

AT_low_pc( 0x000f197c )

AT_high_pc( 0x000f1bcc )

AT_frame_base( r7 )

AT_object_pointer( {0x002db1cd} )

AT_name( "-[className functionName]" )

AT_decl_file( "appName/filepath" )

AT_decl_line( 57 )

AT_prototyped( 0x01 )

AT_APPLE_isa( 0x01 )

0x002db1f8:TAG_lexical_block [18] *

AT_low_pc( 0x000f19b8 )

AT_high_pc( 0x000f1bbc )

0x002db201:TAG_lexical_block [18] *

AT_low_pc( 0x000f19be )

AT_high_pc( 0x000f1bbc )

Line table dir : 'appName/filePath'

Line table file: 'fileName.m' line 73, column 13 with start address 0x00000000000f1a9c

Looking up address: 0x00000000000f1acf in .debug_frame... found!

0x00019820: FDE

length: 0x0000000c

CIE_pointer: 0x00000000

start_addr: 0x000f197c -[className functionName]

range_size: 0x00000250 (end_addr = 0x000f1bcc)

Instructions: 0x000f197c: CFA=sp

看结果可以发现：有AT_name、Line table dir :、Line table file:， 从这些地方可以找到出错的位置。

从这里只用到了dwarfdump的两个功能，想查看其他功能的可以使用

dwarfdump --help

来查看功能介绍。

参考文章：解析IOS崩溃日志(crash Log)