iOS crash符号定位

$ dwarfdump --uuid eif-ios-app.app2.0.1.dSYM

UUID: 29FB573E-D9F6-3C75-A0F3-BC1767940073 (armv7) eif-ios-app.app2.0.1.dSYM/Contents/Resources/DWARF/eif-ios-app

UUID: 33BE41CB-612E-3F29-AE4D-40C12AF4BF1C (arm64) eif-ios-app.app2.0.1.dSYM/Contents/Resources/DWARF/eif-ios-app

比对此uuid和crashlog里的uuid是否匹配，匹配则继续

$ dwarfdump --arch arm64 --lookup 0x1000ff4d0 eif-ios-app.app2.0.1.dSYM（此处arch必须和crash log的arch对应）

或：

1

$ atos -arch  -o /Contents/Resources/DWARF/ -l  

例如：

$ atos -arch armv7 -o /Users/hengda/Downloads/eif-ios-app.app2.0.1.dSYM/Contents/Resources/DWARF/eif-ios-app -l 0x4000 0x3ddb8b

输出中的如下内容即为要找的符号：

Line table file: 'HomeViewController.m' line 163, column 5 with start address 0x00000001000ff4bc

补充：

一、错误报告中的三种地址：

stack address

load address

symbol address

1）stack address

同意词：runtime address

从操作系统的堆栈0点算起，

2）load address

同意词或近意词：base address, slide address,start address

应用堆栈在操作系统堆栈中的起点。

3）symbol address

同意词：relative address

以load address为起点算起的偏移量。

注意：在崩溃报告中，此值为stack address - load address。

在dSYM文件中，一般设定load address为0x4000，这个值可用otool查。

所以在用symbol address在dSYM文件中查找对应的symbol时，需要 加 0x4000。

二、两种格式的崩溃报告：

1、

appname  0x97525 appname + 615717

2、

appname 0x97525  0x29000    + 615717

两种格式的对比：

app name  0x97525（stack address）                                          appname  + 615717 (symbol address)

appname  0x97525（stack address）  0x29000(load address)                      + 615717(symbol address)

一定注意计算时进制转换：symbol address是10进制，其它两个是16进制，以0x开头。

两种格式的区别就是第一种比第二种少了load address。

三、

三个地址间的运算关系：

symbol_address  =  stack_address  -  load_address

由此可以推算出：

load_address =  stack_address - symbol_address

四、由地址得到symbol的命令：

命令行中的地址都必须转为16进制。

1、atos -o  appname.app.dSYM/Contents/Resources/DWARF/appname -arch armv7  symbol_address + 0x4000

3、atos -o MyApp.app/MyApp -arch armv7 -l stack_address load_address

2、dwarfdump -arch armv7 appname.app.dSYM --lookup  symbol_address + 0x4000