Symbolicating iPhone App Crash Reports

I'm looking to try and symbolicate my iPhone app's crash reports.

I retrieved the crash reports from iTunes Connect. I have the application binary that I submitted to the App Store and I have the dSYM file that was generated as part of the build.

I have all of these files together inside a single directory that is indexed by spotlight.

What now?

I have tried invoking:

symbolicatecrash crashreport.crash myApp.app.dSYM

and it just outputs the same text that is in the crash report to start with, not symbolicated.

Am I doing something wrong?


Steps to analyze crash report from apple:

  • Copy the release .app file which was pushed to the appstore, the .dSYM file that was created at the time of release and the crash report receive from APPLE into a FOLDER.

  • OPEN terminal application and go to the folder created above (using cd command)

  • Run atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH . The memory location should be the one at which the app crashed as per the report.

  • Ex: atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508

    This would show you the exact line, method name which resulted in crash.

    Ex: [classname functionName:]; -510 [classname functionName:]; -510

    Symbolicating IPA

    if we use IPA for symbolicating - just rename the extention .ipa with .zip , extract it then we can get a Payload Folder which contain app. In this case we don't need .dSYM file.

    Note

    This can only work if the app binary does not have symbols stripped. By default release builds stripped the symbols. We can change it in project build settings "Strip Debug Symbols During Copy" to NO.

    More details see this post


    After reading all these answers here in order to symbolicate a crash log (and finally succeeding) I think there are some points missing here that are really important in order to determine why the invocation of symbolicatecrash does not produce a symbolicated output.

    There are 3 assets that have to fit together when symbolicating a crash log:

  • The crash log file itself (ie example.crash ), either exported from XCode's organizer or received from iTunes Connect.
  • The .app package (ie example.app ) that itself contains the app binary belonging to the crash log. If you have an .ipa package (ie example.ipa ) then you can extract the .app package by unzipping the .ipa package (ie unzip example.ipa ). Afterwards the .app package resides in the extracted Payload/ folder.
  • The .dSYM package containing the debug symbols (ie example.app.dSYM )
  • Before starting symbolication you should check if all those artifacts match, which means that the crash log belongs to the binary you have and that the debug symbols are the ones produced during the build of that binary.

    Each binary is referred by a UUID that can be seen in the crash log file:

    ...
    Binary Images:
    0xe1000 -    0x1f0fff +example armv7  <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
    0x2febf000 - 0x2fedffff  dyld armv7s  <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
    ...
    

    In this extract the crash log belongs to an app binary image named example.app/example with UUID aa5e633efda8346cab92b01320043dc3 .

    You can check the UUID of the binary package you have with dwarfdump:

    dwarfdump --uuid example.app/example
    UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example
    

    Afterwards you should check if the debug symbols you have also belong to that binary:

    dwarfdump --uuid example.app.dSYM
    UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example
    

    In this example all assets fit together and you should be able to symbolicate your stacktrace.

    Proceeding to the symbolicatecrash script:

    In Xcode 8.3 you should be able to invoke the script via

    /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log
    

    If it is not there you may run a find . -name symbolicatecrash find . -name symbolicatecrash in your Xcode.app directory to find it.

    As you can see there are no more parameters given. So the script has to find your application binary and debug symbols by running a spotlight search. It searches the debug symbols with a specific index called com_apple_xcode_dsym_uuids . You can do this search yourself:

    mdfind 'com_apple_xcode_dsym_uuids = *'
    

    resp.

    mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"
    

    The first spotlight invocation gives you all indexed dSYM packages and the second one gives you the .dSYM packages with a specific UUID. If spotlight does not find your .dSYM package then symbolicatecrash will neither. If you do all this stuff eg in a subfolder of your ~/Desktop spotlight should be able to find everything.

    If symbolicatecrash finds your .dSYM package there should be a line like the following in symbolicate.log :

    @dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )
    

    For finding your .app package a spotlight search like the following is invoked by symbolicatecrash :

    mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"
    

    If symbolicatecrash finds your .app package there should be the following extract in symbolicate.log :

    Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
    Found executable <SOME_PATH>/example.app/example
    -- MATCH
    

    If all those resources are found by symbolicatecrash it should print out the symbolicated version of your crash log.

    If not you can pass in your dSYM and .app files directly.

    symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log
    

    Note: The symbolicated backtrace will be output to terminal, not symbolicate.log .


    With the latest version of Xcode (3.2.2), you can drag and drop any crash reports into the Device Logs section of the Xcode Organiser and they will automatically by symbolicated for you. I think this works best if you built that version of the App using Build & Archive (also part of Xcode 3.2.2)

    链接地址: http://www.djcxy.com/p/44964.html

    上一篇: iPhone Crash Log不包含方法或行号

    下一篇: 具有符号性的iPhone应用程序崩溃报告