How to symbolicate crash log Xcode?

后端 未结 12 1061
别那么骄傲
别那么骄傲 2020-11-22 12:28

Xcode 5 organizer had a view which would list all the crash logs. and we could drag drop crash logs here. But since Xcode 6, I know they have moved devices out of organize a

相关标签:
12条回答
  • 2020-11-22 13:12

    Xcode 11.2.1, December 2019

    Apple gives you crash log in .txt format , which is unsymbolicated

    **

    With the device connected

    **

    • Download ".txt" file , change extension to ".crash"
      • Open devices and simulators from window tab in Xcode
      • select device and select device logs
      • drag and drop .crash file to the device log window

    We will be able to see symbolicated crash logs over there

    Please see the link for more details on Symbolicating Crash logs

    0 讨论(0)
  • 2020-11-22 13:13

    Writing this answer as much for the community as for myself.

    If there ever are problems symbolicating a crash report, one can overcome them as follows:

    1. Create a separate folder, copy Foo.app and Foo.app.dSYM from the corresponding .xcarchive into the folder. Also copy the .crash report into the folder.

    2. Open the crash report in TextEdit or elsewhere, go to the Binary Images: section, and copy the first address there (e.g. 0xd7000).

    3. cd into the folder. Now you can run the following command:

      xcrun atos -o Foo.app/Foo -arch arm64 -l 0xd7000 0x0033f9bb

    This will symbolicate the symbol at address 0x0033f9bb. Please make sure to pick the correct value for the -arch option (can be obtaned from the first line in the Binary Images: section, or figured out from the Hardware Model: in the crash report and the app's supported archs).

    You can also copy the necessary addresses (e.g. a thread call stack) from the crash report directly into a text file (in TextEdit, hold Option and select the necessary text block, or copy and cut), to get something like this:

    0x000f12fb
    0x002726b7
    0x0026d415
    0x001f933b
    0x001f86d3
    

    Now you can save this into a text file, e.g. addr.txt, and run the following command:

    xcrun atos -o Foo.app/Foo -arch arm64 -l 0xd7000 -f addr.txt
    

    This will give a nice symbolication for all the addresses at once.

    P.S.

    Before doing the above, it's worth checking that everything is set up correctly (as atos will happily report something for basically any supplied address).

    To do the checking, open the crash report, and go to the end of the call stack for Thread 0. The first line from the end to list your app (usually the second one), e.g.:

    34  Foo                    0x0033f9bb 0xd7000 + 2525627
    

    should be the main() call. Symbolicating the address (0x0033f9bb in this case) as described above should confirm that this is indeed main() and not some random method or function.

    If the address is not that of main(), check your load address (-l option) and arch (-arch option).

    P.P.S.

    If the above doesn't work due to bitcode, download the dSYM for your build from iTunes Connect, extract the executable binary from the dSYM (Finder > Show Package Contents), copy it into the directory, and use it (i.e. Foo) as the argument to atos, instead of the Foo.app/Foo.

    0 讨论(0)
  • 2020-11-22 13:18

    Make sure that your Xcode application name doesn't contain any spaces. This was the reason it didn't work for me. So /Applications/Xcode.app works, while /Applications/Xcode 6.1.1.app doesn't work.

    0 讨论(0)
  • 2020-11-22 13:19

    If you have the .dSYM and the .crash file in the same sub-folder, these are the steps you can take:

    1. Looking at the backtrace in the .crash file, note the name of the binary image in the second column, and the address in the third column (e.g. 0x00000001000effdc in the example below).
    2. Just under the backtrace, in the "Binary Images" section, note the image name, the architecture (e.g. arm64) and load address (0x1000e4000 in the example below) of the binary image (e.g. TheElements).
    3. Execute the following:

    $ atos -arch arm64 -o TheElements.app.dSYM/Contents/Resources/DWARF/TheElements -l 0x1000e4000 0x00000001000effdc -[AtomicElementViewController myTransitionDidStop:finished:context:]

    Authoritative source: https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS

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

    Follow these steps in Xcode 10 to symbolicate a crash log from an app build on the same machine:

    1. Inside Organizer, locate the archive where the app is based on.
    2. Click on the Download Debug Symbols button. Nothing will appear in your Downloads folder, but that's OK.
    3. Connect the build machine to an iOS device.
    4. Select the device in Devices and Simulators.
    5. Click on the View Devices Logs button.
    6. Drag-and-drop the crash file to the left panel. The file must end with a .crash extension, otherwise the drag fails.
    7. Switch to the All Logs tab.
    8. Select the added crash file.
    9. The file should automatically symbolicate, otherwise use the right-click context menu item Re-Symbolicate Log.
    0 讨论(0)
  • 2020-11-22 13:23

    Apple gives you crash log in .txt format , which is unsymbolicated

    **

    With the device connected

    **

    • Download ".txt" file , change extension to ".crash"
      • Open devices and simulators from window tab in Xcode
      • select device and select device logs
      • drag and drop .crash file to the device log window

    We will be able to see symbolicated crash logs over there

    Please see the link for more details on Symbolicating Crash logs

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