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)
网友评论