I face to the following issue with iOS app (XCode 10.3):
Crashlytics says that I have a missing dSYM, and provides the missing dSYM UUID (I have both required and optional UUIDs missing)
The app is BitCode app, and dSYMs are downloaded from AppStore, and uploaded to Crashlytics. I see many other crashes from the other dSYMs that were downloaded and de-symbolicate correctly.
The app is multi-target app. Before, when the app was just single target app, everything worked fine. The additional targets seems to be an issue.
All targets have BitCode and DWARF with dSYM selected
All targets call Crashlytics run in build phase (at least I believe I do this correctly)
Targets are watch app, watch app extension, Siri intent, Siri intent UI, and the iOS app widget.
I have manually opened the downloaded dSYM from AppStore and the missing dSYM UUID is really missing.
I also checked the locally built app archive, and the dSYM UUID is not there (yes, expected result)
Any idea, where to get the missing dSYM, would make a bit happier... Please.
Sometimes the UUIDs that are assigned on appstoreconnect are incorrect. The crash reports contain the correct ones -- i.e. the stack trace attributes a line to the correct binary image.
In the case of the uploaded dsyms having incorrect UUIDs Crashlytics is not able to match the line in the stack trace to any uploaded dsyms so it flags them as missing.
But there is a way to rewrite the UUID of a dsym and then re-upload it to crashlytics.
Note: This method is risky. If you overwrite the dSYM's UUID with an incorrect one and then upload it to Crashlytics, there is no way to correct that mistake. So you need to be absolutely sure that you A) are looking for the correct binary image; and B) that you have the correct UUID.
Here is how to do it:
Step A: In Crashlytics:
Note down the version of the build for which a dsym is missing
Note down the UUID of the missing dsym
Step B: Find an unsymbolicated line in one of your crash files for that version:
(note: in most cases it's your app's binary image, in which case you can just skip all steps here and then just use your app's name as binary image)
Open Xcode -> Window -> Organiser
In the left-hand pane, select Crashes
Use the drop-down menu in the top left-hand corner to select the version you are interested in
Once all the crashes for that version are downloaded, locate the crash you are interested in
Find the line in the crash report you are interested in and which is not symbolicated
Note down the binary image
Step C-a: Locate and replace the dsym with the incorrect UUID manually:
Open Xcode -> Window -> Organiser
In the left-hand pane, select Archives
Select the archive that corresponds to the version you noted down in Step A)
In the right hand pane, select Download Debug Symbols
Once finished downloading, in the Organiser right click the archive -> Show in Finder
In Finder, right click the archive -> Show Package Contents
Go to the dSYMs directory
Optional: Sort the finder list by Size in DESC order
Starting from the top, right click the first dsym file -> Show Package Contents
Navigate to Contents -> Resources -> Dwarf
Compare the name of the file inside the Dwarf directory with the binary image name you noted down in Step B) 6.
If it matches, follow the steps outlined in this excellent writeup to replace the UUID manually
If it doesn't match, repeat step 9 - 11, going through all dsym files until you found the right one
Step C-b: Locate and replace the dsym with the incorrect UUID automatically:
Open Xcode -> Window -> Organiser
In the left-hand pane, select Archives
Select the archive that corresponds to the version you noted down in Step A)
In the right hand pane, select Download Debug Symbols
Once finished downloading, in the Organiser right click the archive -> Show in Finder
In Finder, right click the archive -> Show Package Contents
Go to the dSYMs directory
Use this command line program to replace the UUID by providing the binary image name and correct UUID
Try using mdfind "com_apple_xcode_dsym_uuids == <UUID>" to find a dSYM witha specific UUID on your machine.
If this doesn't work then my hunch is that crashlytics catches crashes from these non-supported targets, also shows missing UUIDs but the dSYM files are not available at all, not even on iTunes Connect.
TL;DR: I did include symbols when uploading to iTunes Connect. Crash log in Organizer shows hex addresses for my code. Xcode 9.4.
(I know this is an very FAQ, but the discussions I've found address command line tools, obsolete versions of Xcode, or getting logs from a physical device. I'm ready to humbly go to a pre-existing answer if so directed.)
What I did
On upload to iTunes Connect, checked (set to true)
Include bitcode for iOS content
Strip Swift symbols
Upload your app's symbols to receive symbolicated reports from Apple
Quote from Apple doc headed "If logs aren't symbolicated":
If you include symbols when you upload your app to iTunes Connect,
the service automatically symbolicates the logs. You don’t need the
symbols on your Mac. [Emphasis added]
(https://help.apple.com/xcode/mac/current/#/dev5d9904b70)
So I should be OK, right?
Opened release version of app project
Opened Organizer window
Selected Archives tab at top
Selected release version Archive
Clicked the "Download dSYMs..." button on the Archive Information pane
According to above quote this should not be necessary
Selected Crashes tab at top
Select a Report from the Report Name list at left
At this point (above screen shot) the stack frames from my app code are in hex.
Hover the cursor over the hex address
Click the gray right-pointing arrow that appears
This opens the document editor, but does not take me to any location in code.
Clicking the "Open in Project..." button has a similar non-effect.
I have an app in beta using TestFlight and I have been noticing crash reports appearing.
most of the reports are this
If I click on the button Open in project in the Organizer it takes me no where
This appears to be an internal crash correct?
How can I find out what UIBarButtonItem is causing the crash?
I Hope this will help you: Apple doc Crash Report , as you can see in the doc in the Listing 4 the crash report is fully symbolicated , Listing 6 shows partially symbolicated crash reports which looks like your case
From Apple Doc
You must keep both the application binary and the .dSYM file in order to be able to fully symbolicate crash reports. You should archive these files for every build that you submit to iTunes Connect. The .dSYM and application binary are specifically tied together on a per-build-basis, and subsequent builds, even from the same source files, will not interoperate with files from other builds. If you use Xcode's Build and Archive command then they will be placed in a suitable location automatically. Otherwise any location searchable by Spotlight (such as your home directory) is fine.
For more information about this you can check portion after Listing 6 in Symbolication
you can use crashlytics for identifying where the app is crashed.It will give the Controller name and line number of code also.
https://docs.fabric.io/ios/index.html Document
Easy to add your project also
The new Xcode 7 "Crashes" tab in the organizer shows a handful of crashes from the AppStore for my app. According to the documentation, there should be a stack trace. However, none of the 6 crashes have symbolicated stack traces:
I've tried clicking "Open in Project" but it's just as useless:
Of course, I included the dsym and debug info when I submitted to the store. I still have the submission build in my organizer, so the dsyms are still present on my machine. How can I get a proper stack trace on this?
Not ideal, but if you right-click an .xccrashpoint file, select "Show Package Contents", you can navigate its folder structure to find the actual .crash file which you can extract and then symbolicate through the command line using steps described here:
Run
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash
Ensure that DEVELOPER_DIR is set:
export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
Short Story:
In Xcode 9.0: "The Crashes Organizer symbolicates unsymbolicated logs, if they are selected, using a local .dSYM indexed by Spotlight. (22550064)"
You can check out more on this in Xcode's Documentation.
Long Story:
When Xcode builds an .xcarchive for a machine code app it generates .dSYM files that are being indexed by Spotlight by default. For an app uploaded with bitcode you can use the Archives organizer to download dSYMs where they are being indexed by Spotlight by default.
If you choose not to include symbol information when uploading your app to the App Store, the crash logs downloaded by the Crashes Organizer will be unsymbolicated. If you have the appropriate .dSYM files that were generated for the app version that crashed, Xcode will automatically symbolicate the crash when you click on the crash to view it. This functionality exists in Xcode 9.0+. You may manually invoke a re-symbolication by right-clicking on the log detail view and clicking "symbolicate".
I'm doing this for the first time in Xcode 10. Right clicking on my crash log and selecting Symbolicate was having no effect. I selected the build in the Archives section of the Organizer window and clicked the "Download Debug Symbols" button in the right-side pane. This didn't seem to do anything, but when I went back to Crashes and told Xcode to symbolicate the same crash again, this time it worked.
You need to have the app's dsyms local. If this was a build uploaded from say, a build box, you won't have them. Head to App Store Connect, click the Activity tab, find your relevant build, and tap into it. The version details screen includes a link to download the dSYMs - do so, and expand the .zip file they download as.
Now back to your crashes in Xcode - they will symbolicate successfully.
Sanity tip: ensure your local source is at the same commit as the crashing release. Otherwise, if the source file has changed since the release, Xcode can dump you on the incorrect line. e.g. line 127 of your source has now moved to line 129 since you added two lines recently... and the crashes view has no idea about those changes. It'll show you line 127 crashing where the crashing code is actually on line 129.
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 and have a new window for the same. But I do not find a place where I view the crash logs which i drag-dropped in Xcode 5 after upping to Xcode 6. Anybody knows the answer ?
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:
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.
Open the crash report in TextEdit or elsewhere, go to the Binary Images: section, and copy the first address there (e.g. 0xd7000).
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.
You can refer this one too, I have written step by step procedure of Manual Crash Re-Symbolication.
Crash Re-Symbolication
STEP 1
Move all the above files (MyApp.app, MyApp-dSYM.dSYM and MyApp-Crash-log.crash) into a Folder with a convenient name wherever you can go using Terminal easily.
For me, Desktop is the most easily reachable place ;)
So, I have moved these three files into a folder MyApp at Desktop.
STEP 2
Now its turn of Finder, Go to the path from following whichever is applicable for your XCODE version.
Use this command to find the symbolicatecrash script file,
find /Applications/Xcode.app -name symbolicatecrash
Xcode 7.3 and newer (Xcode 8, ..., Xcode 14, ...): /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
STEP 3
Add the found symbolicatecrash script file's directory to $PATH env variable like this: sudo vim /etc/paths.d/Xcode-symbolicatecrash and paste the script file's directory and save the file. When opening a new terminal, you can call symbolicatecrash at any folder as commands located in /usr/bin.
Or
Copy symbolicatecrash file from this location, and paste it to the Desktop/MyApp
(Wait… Don’t blindly follow me, I am pasting sybolicatecrash file in folder MyApp, one that you created in step one at your favorite location, having three files.)
STEP 4
Open Terminal, and CD to the MyApp Folder.
cd Desktop/MyApp — Press Enter
export DEVELOPER_DIR=$(xcode-select --print-path)
— Press Enter
./symbolicatecrash -v MyApp-Crash-log.crash MyApp.dSYM
— Press Enter
That’s it! Symbolicated logs are on your terminal…
Now simply, find out the Error and resolve it ;)
Ok I realised that you can do this:
In Xcode > Window > Devices, select a connected iPhone/iPad/etc top left.
View Device Logs
All Logs
You probably have a lot of logs there, and to make it easier to find your imported log later, you could just go ahead and delete all logs at this point... unless they mean money to you. Or unless you know the exact point of time the crash happened - it should be written in the file anyway... I'm lazy so I just delete all old logs (this actually took a while).
3a. Make sure the log file has the extension .crash (rather than .txt or .ips)
Just drag and drop your file into that list. It worked for me.
For me the .crash file was enough. Without .dSYM file and .app file.
I ran these two commands on the mac where I build the archive and it worked:
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash /yourPath/crash1.crash > /yourPath/crash1_symbolicated.crash
There is an easier way using Xcode (without using command line tools and looking up addresses one at a time)
Take any .xcarchive file. If you have one from before you can use that. If you don't have one, create one by running the Product > Archive from Xcode.
Right click on the .xcarchive file and select 'Show Package Contents'
Copy the dsym file (of the version of the app that crashed) to the dSYMs folder
Copy the .app file (of the version of the app that crashed) to the Products > Applications folder
Edit the Info.plist and edit the CFBundleShortVersionString and CFBundleVersion under the ApplicationProperties dictionary. This will help you identify the archive later
Double click the .xcarchive to import it to Xcode. It should open Organizer.
Go back to the crash log (in Devices window in Xcode)
Drag your .crash file there (if not already present)
The entire crash log should now be symbolicated. If not, then right click and select 'Re-symbolicate crash log'
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
Follow these steps in Xcode 10 to symbolicate a crash log from an app build on the same machine:
Inside Organizer, locate the archive where the app is based on.
Click on the Download Debug Symbols button. Nothing will appear in your Downloads folder, but that's OK.
Connect the build machine to an iOS device.
Select the device in Devices and Simulators.
Click on the View Devices Logs button.
Drag-and-drop the crash file to the left panel. The file must end with a .crash extension, otherwise the drag fails.
Switch to the All Logs tab.
Select the added crash file.
The file should automatically symbolicate, otherwise use the right-click context menu item Re-Symbolicate Log.
You need access to the .dSYM package (folder) that contains a DWARF file, and you should open the .crash file with an editor.
Looking at the backtrace section, you should see something like this:
...
13 TheElements 0x0000000100f62ca0 0x100f5c000 + 27808
14 UIKitCore 0x00000001843e3044 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 356 (UIApplication.m:2328)
...
Binary Images:
0x100f5c000 - 0x101673fff TheElements arm64 ...
...
Note the long address in the stacktrace section, the 3rd column (0x0000000100f62ca0)
Note the short address in the 4th column (0x100f5c000)
Note the architecture in the Binary Images section (arm64)
Execute the following:
$ atos -arch <arch> -o TheElements.app.dSYM/Contents/Resources/DWARF/TheElements -l <short_address> <long_address>
You should get a result like this:
-[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
Note: if for any reason you don't have access to the .dSYM file, you can recreate the .xcarchive using Xcode>Product>Archive, but make sure you are building the exact same code. Then you can extract the symbols from inside the .xcarchive package.
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.
From Apple's docs:
Symbolicating Crash Reports With Xcode
Xcode will automatically attempt to symbolicate all crash reports that it encounters. All you need to do for symbolication is to add the crash report to the Xcode Organizer.
Connect an iOS device to your Mac
Choose "Devices" from the "Window" menu
Under the "DEVICES" section in the left column, choose a device
Click the "View Device Logs" button under the "Device Information" section on the right hand panel
Drag your crash report onto the left column of the presented panel
Xcode will automatically symbolicate the crash report and display the results
To symbolicate a crash report, Xcode needs to be able to locate the following:
The crashing application's binary and dSYM file.
The binaries and dSYM files for all custom frameworks that the application links against. For frameworks that were built from source with the application, their dSYM files are copied into the archive alongside the application's dSYM file. For frameworks that were built by a third-party, you will need to ask the author for the dSYM file.
Symbols for the OS that the that application was running on when it crashed. These symbols contain debug information for the frameworks included in a specific OS release (e.g, iOS 9.3.3). OS symbols are architecture specific - a release of iOS for 64-bit devices won't include armv7 symbols. Xcode will automatically copy OS symbols from each device that you connect to your Mac.
If any of these are missing Xcode may not be able to symbolicate the crash report, or may only partially symbolicate the crash report.
The easiest process to symbolicate crash logs:
preserve the xcarchive file from the organizer during IPA building process for future use.
When the crash occurs, collect the crash logs from affected device. The extension should be .crash. If the crash log is in .ips format, just rename it to .crash.
Double click the xcarchive from the stored path to make it appear in organizer(if not present already).
open in xcode window->devices and simulators -> view device logs -> all logs -> drag and drop the .crash file.
Wait for 5secs. Bang! the application calls in stack trace will be symbolicated!
You may still see a lot of symbols though! those are internal library and framework calls.
This is the easiest one, tried and tested!
I was struggling to have the crash report symbolicated through atos but I was reluctant as the process seems cumbersome, But I found the crash report in the Xcode-> Window -> Organizer->Crashes(in left-side menu) Xcode will automatically download the crash logs and will symbolicate automatically, From there you can easily find the reason of the crash.