iOS crash log 解析 symbol address = stack address - slide 运行时获取slide的api 利用dwarfdump从dsym文件中得到symbol

于 2015-12-26 12:38:07 发布
阅读量4.1k 收藏 5
点赞数 2
分类专栏： iOS 文章标签： ios
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xiaofei125145/article/details/50408051
版权

概述：

为什么 crash log 内 Exception Backtrace 部分的地址（stack address）不能从 dsym 文件中查出对应的代码？

因为 ASLR（Address space layout randomization），因为 ASLR 引入了一个 slide （偏移） 。

 symbol address = stack address - slide;

slide 可以在运行时 由 API 获取到 

dyld_get_image_vmaddr_slide()

也可以根据运行时的 binary image 和   ELF 文件的 load command 计算的到。

 slide = (运行时)load address - (链接时)load address;

注意，如果你没有在运行时用 api 获取slide，那么 binary image 就必须要收集，否则你无法从dsym 文件中解析出符号。



这是一个 iOS crash log 文件，为了简洁删除了部分不需要的内容

Incident Identifier: 975CF16A-5259-4DD1-BFDA-D1B155EF5BF0
CrashReporter Key:   562a7cefe034ac086cae453c61278cdd9a4b3288
Hardware Model:      iPad4,1
Process:             MedicalRecordsFolder [382]
Path:                /var/mobile/Applications/05C398CE-21E9-43C2-967F-26DD0A327932/MedicalRecordsFolder.app/MedicalRecordsFolder
Identifier:          com.xingshulin.MedicalRecordIOS
Version:             1 (4.14.0)
Code Type:           ARM-64 (Native)
Parent Process:      launchd [1]


Date/Time:           2015-12-03 19:14:59.921 +0800
OS Version:          iOS 7.1.2 (11D257)
Report Version:      104




Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread:  0


Last Exception Backtrace:
0   CoreFoundation               0x189127100 __exceptionPreprocess + 132
1   libobjc.A.dylib              0x1959e01fc objc_exception_throw + 60
2   CoreFoundation               0x189127040 +[NSException raise:format:] + 128
3   MedicalRecordsFolder         0x100a8666c 0x10003c000 + 10790508
4   libsystem_platform.dylib     0x19614bb0c _sigtramp + 56
5   MedicalRecordsFolder         0x1006ef164 0x10003c000 + 7024996
6   MedicalRecordsFolder         0x1006e8580 0x10003c000 + 6997376
7   MedicalRecordsFolder         0x1006e8014 0x10003c000 + 6995988
8   MedicalRecordsFolder         0x1006e7c94 0x10003c000 + 6995092
9   MedicalRecordsFolder         0x1006f2460 0x10003c000 + 7038048
10  libdispatch.dylib            0x195fb8014 _dispatch_call_block_and_release + 24
11  libdispatch.dylib            0x195fb7fd4 _dispatch_client_callout + 16
12  libdispatch.dylib            0x195fbe4a8 _dispatch_queue_drain + 640
13  libdispatch.dylib            0x195fba4c0 _dispatch_queue_invoke + 68
14  libdispatch.dylib            0x195fbf0f4 _dispatch_root_queue_drain + 104
15  libdispatch.dylib            0x195fbf4fc _dispatch_worker_thread2 + 76
16  libsystem_pthread.dylib      0x19614d6bc _pthread_wqthread + 356
17  libsystem_pthread.dylib      0x19614d54c start_wqthread + 4


Thread 0 Crashed:
0   libsystem_kernel.dylib        0x00000001960ce58c __pthread_kill + 8
1   libsystem_c.dylib             0x0000000196062804 abort + 108
2   libc++abi.dylib               0x0000000195288990 abort_message + 84
3   libc++abi.dylib               0x00000001952a5c28 default_terminate_handler() + 296
4   libobjc.A.dylib               0x00000001959e04d0 _objc_terminate() + 124
5   libc++abi.dylib               0x00000001952a3164 std::__terminate(void (*)()) + 12
6   libc++abi.dylib               0x00000001952a2d38 __cxa_rethrow + 140
7   libobjc.A.dylib               0x00000001959e03a4 objc_exception_rethrow + 40
8   CoreFoundation                0x0000000189025e48 CFRunLoopRunSpecific + 572
9   GraphicsServices              0x000000018ecb5c08 GSEventRunModal + 164
10  UIKit                         0x000000018c156fc0 UIApplicationMain + 1152
11  MedicalRecordsFolder          0x000000010018fc70 0x10003c000 + 1391728
12  libdyld.dylib                 0x0000000195fd3a9c start + 0


Thread 1:
0   libsystem_kernel.dylib        0x00000001960b5aa8 kevent64 + 8
1   libdispatch.dylib             0x0000000195fb9998 _dispatch_mgr_thread + 48
....


Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x0000000000000000   x2: 0x0000000000000000   x3: 0xffffffffffffffff
    x4: 0x0000000000003060   x5: 0x000000016fdc3530   x6: 0x000000000000006e   x7: 0x0000000000000640
    x8: 0x0000000008000000   x9: 0x0000000004000000  x10: 0x0000000098efe6f7  x11: 0x0000000198efde94
   x12: 0x000000000000006f  x13: 0x0000000000000000  x14: 0x0000000000000000  x15: 0x000000019607bdcb
   x16: 0x0000000000000148  x17: 0x004b96d3524ed02c  x18: 0x0000000000000000  x19: 0x0000000000000006
   x20: 0x0000000198f112a0  x21: 0x434c4e47432b2b00  x22: 0x434c4e47432b2b00  x23: 0x0000000000000001
   x24: 0x00000001701578c0  x25: 0x0000000000000001  x26: 0x0000000170002ea0  x27: 0x00000001963e1410
   x28: 0x0000000000000000  fp: 0x000000016fdc34b0   lr: 0x000000019615116c
    sp: 0x000000016fdc3490   pc: 0x00000001960ce58c cpsr: 0x00000000




Binary Images:
0x10003c000 - 0x100f7bfff MedicalRecordsFolder arm64  <b5ae3570a013386688c7007ee2e73978> /var/mobile/Applications/05C398CE-21E9-43C2-967F-26DD0A327932/MedicalRecordsFolder.app/MedicalRecordsFolder
0x12007c000 - 0x1200a3fff dyld arm64  <628da833271c3f9bb8d44c34060f55e0> /usr/lib/dyld
.......

现在来指出其中比较重要的部分

uuid信息

Incident Identifier: 975CF16A-5259-4DD1-BFDA-D1B155EF5BF0
这行指出文件的 uuid ，根据次 uuid 可确定 dsym 文件是否匹配

确定方法如下,后面会打印出该 dsym 文件内所有 架构的 uuid ，看一下 是否包含 就知道了

dwarfdump --uuid MedicalRecordsFolder.app.dSYM/

  arch信息不解释

Code Type:           ARM-64 (Native)

下面是 异常信息，异常线程 为 thread 0

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread:  0


接下来看 抛出异常的线程的函数调用栈信息 

左侧
第一列，调用顺序 
第二列，对应函数所属的 binary image 
第三列，stack address  
第四列，地址的符号＋偏移的表示法，实质内容跟第三列一样（此列不理解也无影响） 

Last Exception Backtrace:
0   CoreFoundation                0x189127100 __exceptionPreprocess + 132
1   libobjc.A.dylib               0x1959e01fc objc_exception_throw + 60
2   CoreFoundation                0x189127040 +[NSException raise:format:] + 128
3   MedicalRecordsFolder          0x100a8666c 0x10003c000 + 10790508
4   libsystem_platform.dylib      0x19614bb0c _sigtramp + 56
5   MedicalRecordsFolder          0x1006ef164 0x10003c000 + 7024996
6   MedicalRecordsFolder          0x1006e8580 0x10003c000 + 6997376
7   MedicalRecordsFolder          0x1006e8014 0x10003c000 + 6995988
8   MedicalRecordsFolder          0x1006e7c94 0x10003c000 + 6995092
9   MedicalRecordsFolder          0x1006f2460 0x10003c000 + 7038048
10  libdispatch.dylib             0x195fb8014 _dispatch_call_block_and_release + 24
11  libdispatch.dylib             0x195fb7fd4 _dispatch_client_callout + 16
12  libdispatch.dylib             0x195fbe4a8 _dispatch_queue_drain + 640
13  libdispatch.dylib             0x195fba4c0 _dispatch_queue_invoke + 68
14  libdispatch.dylib             0x195fbf0f4 _dispatch_root_queue_drain + 104
15  libdispatch.dylib             0x195fbf4fc _dispatch_worker_thread2 + 76
16  libsystem_pthread.dylib       0x19614d6bc _pthread_wqthread + 356
17  libsystem_pthread.dylib       0x19614d54c start_wqthread + 4

我们从 binary image 这列里面可以看出 好多都是 动态库调用，动态库也就是说 这是 sdk 里面的东西，即使出了bug 你也修复不了，所以我们需要关心的就只有

第 3、5、6、7、8、9、这些行 ，只有这行行对应的代码 才是你自己的 创作（我工程名就是MedicalRecordsFolder）

是 函数调用顺序是 从下往上，也就是说 第 3 行对应的函数才是出问题时 正在执行的代码片段。

所以 从 dsym 中找到 第三行对应的 符号信息 才可能定位到 问题代码。

第三行第三列 

0x100a8666c ，这是 stack address ，注意是 stack address，如果系统没有 ASLR 的话，用这个 stack address 就能在dsym 中找到对应符号信息，但是事实 iOS是有 ASLR 的 。

ASLR 技术Address space layout randomization,ASLR通过将系统可执行程序随机装载到内存里，从而防止缓冲区溢出攻击 

由于 ASLR 的缘故，导致 程序crash后生成的crash log 中的  stack address 与 对应的 symbol address 不一致，有一个偏移量 slide，slide是程序装在时随机生成的随机数。

引入新的概念：

stack address 

： 程序运行时线程栈中 所有 函数调用的地址

symble address 

： dsym文件中函数符号对应的地址，用此地址 在 dsym 文件中可以 查出对应的 符号信息。 

无 ASLR 机制时  stack address 等于symble address 。

定义 slide

在ASLR机制下每次启动APP 装在之前 ，会在连接时指定的 进程空间上 加上一个随意的 偏移量，这个偏移量就是 slide。

 很简单  symble address ＝ stack address －slide；

但是这个 slide 每次 启动 程序都不同，如何 知道 当时启动时 slide 的值呢 ？ 带着疑问继续吧

Load Command

一个 iOS 程序编译链接完之后，生成一个 ELF 二进制文件（也就是程序运行时的映射文件），该文件的详细格式不再赘述，这里只强调一个 segment  _TEXT

下面是 使用 otool 工具查看到的  MedicalRecordsFolder（我的demo程序）的 加载命令 。

$otool -l MedicalRecordsFolder.app/MedicalRecordsFolder 
MedicalRecordsFolder.app/MedicalRecordsFolder:
Load command 0
      cmd LC_SEGMENT_64
  cmdsize 72
  segname __PAGEZERO
   vmaddr 0x0000000000000000
   vmsize 0x0000000100000000
  fileoff 0
 filesize 0
  maxprot 0x00000000
 initprot 0x00000000
   nsects 0
    flags 0x0
Load command 1
      cmd LC_SEGMENT_64
  cmdsize 792
  segname __TEXT
   vmaddr 0x0000000100000000
   vmsize 0x000000000000c000
  fileoff 0
 filesize 49152
  maxprot 0x00000005
 initprot 0x00000005
   nsects 9
    flags 0x0


……


Load command 2
      cmd LC_SEGMENT_64
  cmdsize 1352
  segname __DATA
   vmaddr 0x000000010000c000
   vmsize 0x0000000000004000
  fileoff 49152
 filesize 16384
  maxprot 0x00000003
 initprot 0x00000003
   nsects 16
    flags 0x0


……


Load command 3
      cmd LC_SEGMENT_64
  cmdsize 72
  segname __LINKEDIT
   vmaddr 0x0000000100010000
   vmsize 0x000000000000c000
  fileoff 65536
 filesize 35056
  maxprot 0x00000001
 initprot 0x00000001
   nsects 0
    flags 0x0

_TEXT 段的加载命令如下，可知到映射文件中segment _TEXT 对应的  虚拟地址空间从 0x0000000100000000 开始 。

segname __TEXT
   vmaddr 0x0000000100000000
   vmsize 0x000000000000c000
  fileoff 0
 filesize 49152
 

 

 

segname __TEXT  就是代码段，也就是说所有的二进制指令
 

没有 ASLR机制时：
 

加载时 装载器会将此 ELF 文件的 前 49152 （offset 0 ，filesize 49152）个字节（因为 offset 0 ，filesize 49152）映射到 进程空间以  0x0000000100000000 开始的一块虚拟内存空间里. 
 

有ASLR 机制时：
 

加载时 装载器会将此 ELF 文件的 前 49152 （offset 0 ，filesize 49152）个字节（因为 offset 0 ，filesize 49152）映射到 进程空间以  0x0000000100000000 （+slide）开始的一块虚拟内存空间里. 
 

所以 ： 如果没有 ASLR 机制，那么运行时的内存布局 就和  Load command 中指定的布局一致，也就意味着stack address和 symbol address 一致
 

有 ASLR 的情况也不复杂，只是 加了一个 随意的偏移量 slide 
 

binary image
 

程序运行时 的  映射 信息，
 

Binary Images:
0x10003c000 - 0x100f7bfff MedicalRecordsFolder arm64  <b5ae3570a013386688c7007ee2e73978> /var/.../MedicalRecordsFolder
0x12007c000 - 0x1200a3fff dyld arm64  <628da833271c3f9bb8d44c34060f55e0> /usr/lib/dyld
 

左侧
 

第一列，虚拟地址空间区块
 

第二列，映射文件 名
 

第三列，uuid吧，还不知道,以后再补上
 

第四列，映射文件路径
 

计算 slide 和 symbol address
 

第一行可以看出  进程空间的 0x10003c000 - 0x100f7bfff 这个区域 在运行时被映射为 MedicalRecordsFolder 内的内容，也就是我们的 ELF 文件。
 

注意这个 区域起始地址 为  0x10003c000 
 

而我们在 Load Command 中看到的却是  0x0000000100000000
 

 

segname __TEXT
   vmaddr 0x0000000100000000
   vmsize 0x000000000000c000
 

显而易见： 
 

slide =  0x10003c000 - 0x100000000 = 0x3c000;
 

symbol address = stack address - slide;
 

stack address 在crash log 中已经找到了。
 

 

用的到的symbol地址去 dsym 文件中 查询，命令如下
 

 

$dwarfdump --arch arm64 --lookup 0x00123 MedicalRecordsFolder.app.dSYM/
 

就可以定位下来具体的 代码 函数名，所处的文件，行 等信息了
 

读取 slide 的 API
 

这个 slide 的计算还是挺 恶心的 ，要 查看 binary image 的到 load address ，还要查看  对用 ELF 中 _TEXT 的 Load Command 虚拟空间范围.
 

如果 自己写一个 模块 来 收集 NSException 的话 ，大可不必这么繁琐，因为 程序 运行时 有 api 是可以 直接获取这个 binary image 对应的  slide 值的 。
 

如下：
 

 

#import <mach-o/dyld.h>
void calculate(void) {
    for (uint32_t i = 0; i < _dyld_image_count(); i++) {
        if (_dyld_get_image_header(i)->filetype == MH_EXECUTE) {
             long slide = _dyld_get_image_vmaddr_slide(i);
            break;
        }
    }
}
 

  这样 就可以 将 stack address 直接 减去 slide 之后 再 上传到自己的  服务端，岂不是 很完美。 

 


 
 


 
 

 

 

 


 

                

        

        

    

  


    

      

        

            

              
                
                  滴水成川
                
              
            

            

                关注
              
            

        

        

          
      

      

            

                专栏目录
          









              

  



          




        



    





    



      

      

        
      

      





	

		
评论 1

	

	
	




  

    

      添加红包
      
    

    

      

        
        

          
          
        

        
请填写红包祝福语或标题

      

      

        
        

          
          个
        

        
红包个数最小为10个

      

      

        
        

          
          元
        

        
红包金额最低5元

      

      

        
        

          当前余额3.43元
          前往充值 >
        

      

      

        

          需支付：10.00元
        

        
        
      

    

  





  

    
    
  

  

    
    
  








  

    

      

        

          

            
            
成就一亿技术人!

          

          

        

        

          

          

            领取后你会自动成为博主和红包主的粉丝
            规则
          

        

      

      

        

          

            
              
            
            

              
hope_wisdom
 发出的红包
            

          

        

        

          

          

          

        

      

    

    

  



      
      

      
实付元

      
使用余额支付

      

        

          

            
            点击重新获取
          

        

        
扫码支付

      

      

        
          
            
          
          
        
      

      

        
        钱包余额
          0
          

            
            

              

                
抵扣说明：

                
 1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

              

            

          

      

      余额充值