Reputation: 2250
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 ?
Upvotes: 223
Views: 187783
Reputation: 9
A great way to see a symbolicated crash report is to
Window -> Organizer
From here you can click on Crashes in the lefthand menu to see crash reports based on the selected app version.
Upvotes: 0
Reputation: 405
The atos
command is used to symbolicate the addresses in a program's stack trace or crash report. It is used to translate memory addresses from a crashed application back into human-readable function names and line numbers.
atos -arch <architecture> -o <executable> -l <load address> <address1> <address2> ...
example
atos -arch arm64 -o MyApp -l 0x1001d0000 0x00000001013425d4 0x0000000101342558 0x000000010144662c 0x0000000101420208
-acrh : for ios arm64 and for macOS x86_64
-o : executable file name.
you can find it in dsyms-> appName.app.dsyms ->right click -> show package content -> Contents -> Resources -> DWARF -> appName. Move that file and crash log into same folder
-l : load address of the executable
Find the address in Binary Image section in your crash log
Upvotes: 0
Reputation: 5023
You can refer this one too, I have written step by step procedure of Manual 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 ;)
Upvotes: 237
Reputation: 16298
Ok I realised that you can do this:
Xcode > Window > Devices
, select a connected iPhone/iPad/etc top left.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
)
Upvotes: 133
Reputation: 2050
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 ...
...
0x0000000100f62ca0
)0x100f5c000
)Binary Images
section (arm64
)$ 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.
Upvotes: 14
Reputation: 660
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.
Upvotes: -1
Reputation: 5883
Xcode 11.2.1, December 2019
Apple gives you crash log in .txt format , which is unsymbolicated
**
With the device connected
**
We will be able to see symbolicated crash logs over there
Please see the link for more details on Symbolicating Crash logs
Upvotes: 18
Reputation: 9131
Follow these steps in Xcode 10 to symbolicate a crash log from an app build on the same machine:
Upvotes: 13
Reputation: 3436
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'
Upvotes: 23
Reputation: 53
The easiest process to symbolicate crash logs:
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!
Upvotes: 2
Reputation: 2481
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
Upvotes: 39
Reputation: 5081
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
.
Upvotes: 286
Reputation: 5805
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.
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.
Upvotes: 3
Reputation: 12138
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.
Upvotes: 4