0x1000ac000最近對項目中添加了crash日志分析，使用到兩個分析工具，分別是騰訊的bugly與友盟的錯誤分析。
開始選擇的是bugly，但是在配置時根據(jù)文檔進(jìn)行接入，但是一直未顯示配置上的成功提醒，咨詢技術(shù)人員后仍不能解決。因為其他的一些統(tǒng)計使用了友盟，所以就直接打開了友盟的錯誤日志。
友盟的錯誤日志經(jīng)?？梢钥吹降腻e誤信息如下：、
在這種情況下它指出了應(yīng)用名稱，崩潰時的調(diào)用方法的地址，文件的地址以及方法所在的行的位置卻很難定位問題所在，這個時候就需要mac上的一個工具------dwarfdump，可以簡便地檢測出app和相應(yīng)的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文件是否相匹配。 匹配查詢內(nèi)存地址定位信息
dwarfdump --arch=armv7 --lookup 0x97525 ?appname.app.dSYM
得到的結(jié)果：
----------------------------------------------------------------------
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
看結(jié)果可以發(fā)現(xiàn)：有AT_name、Line table dir :、Line table file:， 從這些地方可以找到出錯的位置。
從這里只用到了dwarfdump的兩個功能，想查看其他功能的可以使用
dwarfdump --help
來查看功能介紹。
參考文章：解析IOS崩潰日志(crash Log)
