how to launch symbolicatecrash from Xcode?
I have a crash file with the address, I want transfer the address into symbol which are in my source code.
When using gdb, we can do that gdb ./yourApplication coredumpfile.
I think xcode should have a similar tool for transfer the address into symbols.
I've detailed how to use symbolicatecrash in one of my blog posts. To summarize, you can find the script at the following location:
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash
Then you execute the script using the following command:
./symbolicatecrash.sh -A -v [crashlog-filename] MyApp.dSYM
Make sure that both, your Symbol file (MyApp.dSYM) and your App binary (MyApp) are both stored in the directory in which you're executing symbolicate crash. For more details, have a look at the full blog post here: http://apptech.next-munich.com/2010/01/symbolicatecrash.html
Note if you try to symbolicate crash, you have to 3 file in a same folder (.app, .dSYM and .crash), and then the importance is make sure the .app and .dSYM file is the lastest file of your app build
Related
I'm using a PC and I've created a build for Mac standalone.
I shared the file with my test user by zipping and emailing the build, but when he tries to run the application he sees this error:
The application "SomeApp.app" can't be opened.
After some searching, I learned that I need to do chmod to open the file. Can anyone tell me how to do that on a Mac?
The zip format doesn't have easy support for Unix-like file permissions, so your transfer process is stripping any permission flags that OSX uses to recognize files within that zip that are supposed to be executable. This can also happen with other file transfer solutions, so it's something to watch out for.
The best solution would be to create an archive which does keep those permissions, such as a tar archive.
Failing that, you can have a Mac user open a terminal and set the permission flag manually:
chmod a+x SomeApp.app/Contents/MacOS/*
(Replace SomeApp.app with whatever your .app folder is named)
I had the same issue, I left an answer here, at the bottom: https://forum.unity.com/threads/mac-build-breaking-when-uploaded-to-storage.1093330/
The problem was not with the .zip, but rather with the build itself. Ran fine on my Mac, did NOT run fine once I uploaded it and downloaded it again (or if anyone else downloaded it).
Edited 12/8/2021, as per EmiOB's suggestion, to add the text of my answer (same as in the link):
This worked for me on 2020.3.16f1:
In the Unity Editor: Build Settings, check the box that lets you make an XCode project (requires having XCode installed, I believe I have Xcode 11)
Open the XCode project
Build
That solved my problem :)
Q1) How can I symbolicate the entire crash log file. I do have DYSM & APP files with me. Using ATOS command is tedious. My symbolicatecrash is not working.
Q2) If I forgot to capture the DYSM & APP files while generating a build, can I generate & use them after some time given that there is no modification done on that code after the build was generated. Will this be as good as capturing these file at the time of build generation?
A1) Just put DSYM, APP and crash files in one directory. Then open XCode Organizer->iPhone development->Device Logs, and just drag & drop crash log to a list. That's all, if you have a proper dsym file, crash log should appear with symbols in a list.
A2) If there are no modifications done on code, compiler and machine where build was generated, there's some chance. But I never succeed in my attempts to do this.
symbolicatecrash is a perl script that uses spotlight to locate the dSYM files that belong to the app that crashed. If you run symbolicatecrash with the -v (verbose) option you'll see something like:
Searching in Spotlight for dsym with UUID of ...
Running mdfind "com_apple_... == ..."
So, be sure that spotlight works, and the indexing for spotlight is active for the volume where your stuff is located, with the mdutil command: mdutil -s -a
If the volume your archived Apps are on is not indexed be sure to switch indexing on. (As root/sudo: mdutil -i on /Volumes/...)
You can also translate symbols manually using atos. Read more on my blog: http://www.dev-smart.com/archives/389
I have a .crash log from an ad-hoc version of my app that symbolicatecrash refuses to symbolicate. I have already applied the .patch to remove the 'die' command in symbolicatecrash after apple broke the script in XCode 3.2.6. Symbolicatecrash has worked for other crash logs but refuses to symbolicate this one. My ad hoc app was built and is stored in "Archived Applications", so there is no reason why XCode shouldn't be able to find it. I have even copied the .app and .dSYM files right next to the .crash log, no dice.
Is there a way I can force symobolicatecrash to use a specific .app and .dsym files even if it doesn't think it applies?
Turns out I accidentally deleted the build associated with the crash log. symbolicatecrash uses the following logic to figure out if there are symbols associated with a crash log:
At the bottom of every crash log is a list of Binary Images. Yours is listed first. There is a guid associated with your binary image. For example:
0x1000 - 0x2befff +MyApp armv7 <a95274a309d73458a40cb5a6fd317a1c> /var/mobile/Applications/91884634-DA1A-4BDB-9E1E-6F487D8F25D7/MyApp.app/MyApp
The relevant guid is: a95274a309d73458a40cb5a6fd317a1c
It next uses the tool mdfind, which looks at metadata associated with files in your file system, for the uppercase and hyphenated form of that GUID.
From your archived applications, if you click on MyApp.app.dSYM, then Get Info, then disclose More Info, you will see dSYM UUIDs and two GUIDs listed. The second GUID is the one that is relevant. It will be of the form:
A95274A3-09D7-3458-A40C-B5A6FD317A1C
Provided that the second GUID matches the guid in the .crash file, symbolicate crash will be able to find and symbolicate. If they don't match, it's the wrong binary.
Cheers,
Eric
OK turns out this answer is now what is required for the latest XCode 5.1.1:
Recently I had a crash log from an ad-hoc build. XCode refused to Symbolicate. I had an archived build a few hours old and I wanted to force a symbolication using my archived build. Here is how I did it:
1) First I opened a terminal window and went to the directory containing my archive. I ran this command:
xcrun dwarfdump --uuid Example.app/Example | tr '[:upper:]' '[:lower:]' | tr -d '-'
This pulled out the dsym_uuid of the archived build. The tr command converts the guid from an uppercase guid with dashes to a lowercase guid with no dashes
2) I went into the .crash file and changed the guid associated with my binary in the crash log to the guid associated with the xcdarchive on my machine
For example, went from
0x80000 - 0x49efff +MyApp armv7 <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa> /var/mobile/Applications/DC23BDC0-75E3-4DCA-8AC3-099889CE22E0/MyApp.app/MyApp
to
0x80000 - 0x49efff +MyApp armv7 <bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb> /var/mobile/Applications/DC23BDC0-75E3-4DCA-8AC3-099889CE22E0/MyApp.app/MyApp
3) From the terminal, I set my DEVELOPER_DIR environment var to:
export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer
4) Finally, I ran this beast of a command:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash -v MyApp.crash /Users/me/Library/Developer/Xcode/Archives/2013-05-31/MyApp\ 5-31-13\ 7.00\ PM.xcarchive/Products/Applications/MyApp.app
Note that the path to symbolicatecrash changes in newer versions of XCode, to:
/Applications/Xcode6.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash
This command run symbolicatecrash against your archive using the .crash file you have
A little additional information which may help.
I have two UUIDs listed, and my first one matches the one in the crash log, not the second. However my crash comes from a device running ARM6, whereas the OPs came from one running ARM7
I therefore deduce that each UUID matches an architecture, if you build for ARM6 and ARM7 and the crash comes from a device running ARM6, then you'll need to match the first UUID, if it is running ARM7 you'll need the second.
If you only have one UUID, I think you probably only built for one architecture.
This is mainly deduction, but seems likely.
There is a new process for extracting build UUIDs described here:
https://developer.apple.com/library/ios/qa/qa1765/_index.html
This is now the magical command to run to extract build UUID:
xcrun dwarfdump --uuid Example.app/Example | tr '[:upper:]' '[:lower:]' | tr -d '-'
I have been able to force symbolicatecrash to symbolicate my crash log by overriding the dSYM UUID to the expected crashlog's UUID.
Put dsym and unsymbolicated.crash in same folder.
Run ./symbolicatecrash in Verbose mode:
./symbolicatecrash unsymbolicated.crash > symbolicated.crash -d ./MyApp.app.dSYM/ -v
Scroll to bottom and find the crashlog's expected UUID:
Did not find dsym for db3e90fa8b6d462c9d65049ab1f22ea4
-- [db3e90fa8b6d462c9d65049ab1f22ea4] NO MATCH (spotlight)
In Finder right click your .dsym file and click "Get Info" under "More Info" section header you will have the dSYM UUIDs: property. Copy this value to clipboard.
Using a hex editor (I used iHex from App Store) open MyApp.dysm/Contents/Resources/DWARF/MyApp and CMD+F the copied UUID.
Replace this UUID with the expected expected one in this example I replaced it with: "db3e90fa8b6d462c9d65049ab1f22ea4".
NOTE: While this is exceptionally hacky and does not guarantee success and will more then likely result in mis-symbolicated crash with nonsensical method names but maybe it will work for you!
I got a crash log from a customer using my iPhone app and trying to get symbolic information out of, and failing spectacularly ... what I found online as instruction is this (to be executed on a Mac):
symbolicatecrash crash-log-file.crash symbol-file.dSYM > report-with-symbols.crash
crash-log-file.crash is the crash log obtained by the user via iTunes, a text file
symbol-file.dSYM is created by XCode each time you build the application and contains the symbols file (within a series of folders)
Unfortunately my attempts have all failed:
- with a version of symbolicatecrash I have (don't recall where & when I found it), the output is identical to the input file, without symbols
- with another version I found on my disk, I get this error message (note: I tried to point to the symbol file itself within the .dSYM tree - still no help):
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash failedstart.crash ScanBizCards.app.dSYM/Contents/Resources/DWARF/ScanBizCards > crashwithsymbols
Can't understand the output from otool ( -> '\/Developer\/Platforms\/iPhoneOS.platform\/Developer\/usr\/bin\/otool -arch armv7 -l /Users/patrickq/Projects/icr/OCR/newOCR/build/Debug-iphonesimulator/ScanBizCards.app/ScanBizCards') at /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash line 301.
Help anyone?
I don't even mind doing the math myself for symbols but don't know how to open the symbols file ...
Patrick
symbolicatecrash is very buggy and try to do smart things to locate your binaries/dsym files using spotlight (mdfind). This line is the clue:
Can't understand the output from otool
( -> '\/Developer\/Platforms\/iPhoneOS.platform\/Developer\/usr\/bin\/otool
-arch armv7 -l
/.../build/Debug-iphonesimulator/ScanBizCards.app/ScanBizCards')
Apparently, it found one of your developement build product (for the simulator) and used it to try to symbolicate a crashreport generated on the device. And it failed miserably, of course.
The exact same problem occurred to two different people at our company. I haven't investigated how the problem happens. I imagine this is quite rare, otherwise, such an enormous bug would have already been fixed. For the moment, I have only this very crude workaround:
Remove all your build folder mentioning this executable name (in your case ScanBizCards.app)
Remove the application from the simulator (I mean, all the incarnations of the application in the various versions of the simulator, like in ~/Library/Application Support/iPhone Simulator/4.3, ~/Library/Application Support/iPhone Simulator/3.2, ...)
This leaves you with the archived applications only. This time, symbolicatecrash can't find a wrong version and eventually find the correct one.
If I ever reproduce the problem, I will take some time to debug this horrible perl script.
I hope that helps.
I have the same issue pointed out by Frederic. To more completely fix the issue, search for sub getSymbolPathFor_dsymUuid in the symbolicatecrash script, and change the following line:
my $cmd = "mdfind \"com_apple_xcode_dsym_uuids == $myuuid\"";
Add this parameter after mdfind:
-onlyin /path/to/your/app/bundles
and use the directory where you are storing your archived bundles. This way, it will always find the correct version of your app. If you want to be extra safe, scroll down a bit to where it says:
my #spotLightSearchForExecutable = `mdfind $executable.app'; # To cover the case where the DSYM's and .app are no located in the same location.
And add the -onlyin /path/to/your/app/bundles as well. This path is only used when, as the comment on the above line states, symbolicatecrash cannot find your .app in the same folder as your .DSYM. Hopefully, if you store them both in the same folder, this should never be run, but if you have any doubts, it's better to be safe and do this too.
It seems that you are running symbolicatecrash for iPhone simulator debug symbols, while you need to pass the path to symbols for iPhone device build
If you use the "Build and Archive" feature from Xcode to distribute the app (to Apple Store or the user), you can drag the crash log to the organizer and let the IDE do symbolication.
Remember, you must have the exact version of the app and .DSYM. Recompiling the app generates a different .DSYM and it will not work.
Trying to debug app. The trouble is I cannot find this program.
symbolicatecrash.sh
sudo cp /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/Resources/symbolicatecrash /usr/local/bin/
Is it a separate download? I am using XCode 3.2.3
Thanks.
EDIT :: XCode 4.3
You will want to follow the same steps as outlined in the original answer (below) with a few exceptions.
First, you need to fix the Xcode path. Open a terminal and run:
/usr/bin/xcode-select -print-path
If it displays "/Developer" or anything but "/Applications/Xcode.app/Contents/Developer/" then it is wrong. To fix this run the command:
sudo /usr/bin/xcode-select -switch
/Applications/Xcode.app/Contents/Developer/
You can now run all the steps below, with the exception that the symbolicatecrash command is in a new spot (again). This is because Xcode now installs as an app. To find symbolicatecrash run this from the terminal:
find /Applications/Xcode.app -name symbolicatecrash -type f
This should return:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash
Before running symbolicatecrash you may wish to go to this directory like:
cd
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/
Original Answer :: Xcode < 4.3
Path for symbolicatecrash
Search from a terminal using:
find /Developer -name symbolicatecrash -type f
For me this returned:
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash
How to Manually Symbolicate a Crash Log
Run the symbolicatecrash command with the crash log as the first argument and your dSYM file as your second argument. Note that if you will be running symbolicatecrash from the current directory that you MUST put ./ in front like ./symbolicatecrash unless your PATH environment variable includes the directory that the command resides in.
I changed to the directory that had the symbolicatecrash command in it first (note: will be different for Xcode 4.3, see top):
cd
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/
Then I executed the following command:
./symbolicatecrash /somePath/MyCrashLogFile.crash
/somePath/MyAppName.app.dSYM
How to Find the dSYM file:
You must have the archive that was used to create the build with the crash to get the dSYM file.
Here are the steps:
Right click (or ctrl click) the archive from organizer and choose "Show in Finder".
From the xcarchive file in finder, right click (or ctrl click) this file and choose "Show Package Contents". You will then see a "dSYMs" folder.
Inside the "dSYMs" folder you will find "YourAppName.app.dSYM" file that you will need to symbolicate files.
A plugin is available for Xcode under the Product menu. This plugin is available through Alcatraz package manager or can be directly downloaded from github.
This plugin internally incorporates a shell script that does the set up of running the following commands for manual crash symbolication.
Set an alias to symbolicatecrash.pl perl script
alias
symbolicatecrash='/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash'
To find symbolicatecrash, should it differ from the alias above:
find /Applications/Xcode.app -name symbolicatecrash -type f
Set the DEVELOPER_DIR variable:
export DEVELOPER_DIR='/Applications/Xcode.app/Contents/Developer'
With the dSYM the crash can be symbolicates as:
symbolicatecrash /path/to/MyApp_2012-10-01_Device.crash
/path/to/MyApp.app.dSYM.
One way to symbolicate a crash log is to run the following command on terminal:
xcrun atos -o MyApp.app/MyApp -arch armv7 -l 0xb7000 -f MyApp.crash
Replace the example hexadecimal number(0xb700) in the command above with the base load address. Base load address is the first memory address in the line immediately after
"Binary Images:"
To get the .app file:
Right click on the xcarchive file and select Show Package Contents
The .app file is in the Products/Applications directory.
I just wrote a post on debugging crash log 5 min ago here: http://just2us.com/2010/10/reading-iphone-crashlog/
You might not need symbolicatecrash.sh anymore if drag and drop the logs to Xcode is good enough for your purpose. I am using 3.2.4, and I can't find the script too.
As Apple explains, Xcode will try to symbolicate automatically. It uses symbolicatecrash and spotlight to do that. However if the app wasn't built locally or it was deleted, then the necessary .app and .dsym files are not available.
So keep around the dsym file and the app of released versions. Build tools will often zip the .dsym file to a .dsym.zip and package the .app as an .ipa. You can unzip both and copy .app and .dsym to the same folder. Then Xcode will be able to find them using spotlight.
Here is a simple method I use:
Open Xcode 6
Plug in your dev device
Within Xcode, go to Window > Devices > Select your device
Press 'View Device Logs'
Drag your report into the window to view it