iOS crash reports: atos not working as expected

前端 未结 4 637
终归单人心
终归单人心 2020-11-22 13:53

I\'m looking at a crash report provided by Apple

Hardware Model:      iPhone4,1
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  la         


        
相关标签:
4条回答
  • 2020-11-22 14:21

    You have to calculate the address to use with atos, you can't just use the one in the stacktrace.

    symbol address = slide + stack address - load address
    
    1. The slide value is the value of vmaddr in LC_SEGMENT cmd (Mostly this is 0x1000). Run the following to get it:

      otool -arch ARCHITECTURE -l "APP_BUNDLE/APP_EXECUTABLE" | grep -B 3 -A 8 -m 2 "__TEXT"
      

      Replace ARCHITECTURE with the actual architecture the crash report shows, e.g. armv7. Replace APP_BUNDLE/APP_EXECUTABLE with the path to the actual executable.

    2. The stack address is the hex value from the crash report.

    3. The load address can be is the first address showing in the Binary Images section at the very front of the line which contains your executable. (Usually the first entry).

    Since in the past value of the slide was equal to value of the load address this always worked. But since Apple introduced Address space layout randomization beginning with iOS 4.3 (in different variations), the apps loading address is randomized for security reasons.

    0 讨论(0)
  • 2020-11-22 14:21

    A simpler alternative: you can use the atos -l flag to make it do the maths for you.

    Say you've got the following line in your crash log that you want to symbolicate:

    5   MyApp                   0x0044e89a 0x29000 + 4348058
    

    The first hex number is the stack address, and the second hex number is the load address. You can ignore the last number. You don't need to worry about slide addresses either.

    To symbolicate, do the following:

    atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a
    

    If you can't find your MyApp.app/MyApp file, rename your '.ipa' file to a '.zip', unzip it, and it'll be in the Payload folder.

    And if you're not sure which architecture to use (for example, armv7 or armv7s), scroll to the 'Binary Images' part of the crash file and you can find it in there.

    Cheers

    0 讨论(0)
  • 2020-11-22 14:25

    For whom that certain times doesn't have the value for Load Address like this:

    Jan 14 11:02:39 Dennins-iPhone AppName[584] <Critical>: Stack Trace: (
        0   CoreFoundation                      0x2c3084b7 <redacted> + 150
        1   libobjc.A.dylib                     0x39abec8b objc_exception_throw + 38
        2   CoreFoundation                      0x2c21cc35 CFRunLoopRemoveTimer + 0
        3   AppName                             0x0005a7db AppName + 272347  
    

    I've created a simple bash to help me debug:

    #! /bin/bash
    read -p "[Path] [App Name] [Stack Address] [DecimalSum] " path appName stackAddress decimalSum
    loadAddress=`echo "obase=16;ibase=10;$((stackAddress-decimalSum))" | bc`
    atos -o $path/Payload/$appName.app/$appName -l $loadAddress $stackAddress -arch armv7
    

    It just reads the path for the app, the app name, the stack address, and the value after "+" signal (the decimal value) and then find the value for load address to run atos command.

    0 讨论(0)
  • 2020-11-22 14:46

    Simply use dwarfdump:

    dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'
    

    No need to do any calculations at all.

    (From Get symbol by address (symbolicating binary, iOS build)).

    0 讨论(0)
提交回复
热议问题