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.
Related
I don't get any symbol names when I'm profiling my iPhone app.
It works in the simulator and when using Debug mode on the device, but not when using Release (as you should use when profiling). I know the dsym-file is generated for both release and debug, so that is not the problem.
I've tried the solution described here:
Missing symbol names when profiling IPhone application with Instruments
But when i choose "Re-Symbolicate Document" my app's name doesn't appear in the binary list (it does appear when using debug), so I can't try to manually add the dsym file.
I've also tried:
Adding and removing my Derived Data folder from Spotlight's Privacy list
Removing the app from the iPhone
Clean & Build before profiling
Removing the Derived Data folder before building and profiling
What can be the problem?
today i also missing symbols when profile on iPhone.
but i ever missing to find dsym file when i build a platform to analyse the crash reports. i remember i fix it by reindex spotlight.
so this time i do it to, because i find in resymbolicate documents, the instruments cannot find the dsym file for specfic udid. so i guess it is caused by system failed to find it with the help of spotlight(system always use mdfind command to find dsym file). if the spotlight failed to find, maybe the instrument cannot find dsym file too ..
so i go search the reindexing command:
sudo mdutil -E /Volumes/Macintosh\ HD
-E will tell the system to reindexing
this command to reindex the root disk. so it may costs some time.
after reindex, it's better for you to give a path to resymbolicate.
it's ok for me to make it work, if you have something don't understand, please let me known. thanks.
I've read about this argument here: UUID mismatch detected with the loaded library
The most voted solution didn't work for me, because I'm sure in my case the problem is Spire.
When I try to run my App [iOS 5.0 targeted] in Xcode 4.2 onto my iPhone 4 [iOS 5.0.1 JB] the output in the console is:
warning: UUID mismatch detected with the loaded library - on disk is:
/Users/myusername/Library/Developer/Xcode/iOS DeviceSupport/5.0.1 (9A405)/Symbols/System/Library/Frameworks/CoreLocation.framework/CoreLocation
unable to load symbol file: warning: Unable to read symbols for /Library/MobileSubstrate/MobileSubstrate.dylib (file not found).
warning: No copy of MobileSubstrate.dylib found locally, reading from memory on remote device. This may slow down the debug session.
Before installing Spire I didn't have any Xcode problem. I've read that somebody already found a solution: https://stackoverflow.com/a/8930742/1203837 but I'm not so practical in approaching the proposed one that I'm going to report also here:
If you have Spire installed and you updated to 5.0.1 you need to uninstall Spire or update dyld_shared_cache which Spire is using...Spire dyld cache is at /var/spire. You need to extract cache appropriate to your current firmware from ipsw.
I really would NOT uninstall Spire, so please help me to find out how to "update dyld_shared_cache which Spire is using" .
EDIT: thanks to kexik I've tested a fully working workaround for the problem.
Whatever device you have installed Spire in, here is the step-by-step guide (Mac OS):
download the original iPhone 4S ipsw ( link )
rename it from .ipsw to .zip
extract it (normally, by double-clicking it in Mac OS X)
download vfdecrypt ( link ) ed unzip it into the same extracted folder of the ipsw.
Open Terminal and navigate into the ipsw extraxted folder (tip: type cd then drag-and-drop directly the folder into the Terminal window)
Run the command:
./vfdecrypt -i 038-3763-001.dmg -o decrypted.dmg -k a31ffd506c6711c5a0c52c9f0a2f7208a2f63ad9dd40506e70d80ea20a981eb1312bc774
NOTE:
-i 038-3763-001.dmg
Is relative to the biggest .dmg in all the ones you can find into the extracted ipsw folder (referred to the Root File System)
-o decrypted.dmg
Is relative to the name of the output decrypted file, I called "decrypted" (the extension .dmg is fixed)
-k a31ffd506c6711c5a0c52c9f0a2f7208a2f63ad9dd40506e70d80ea20a981eb1312bc774
Is relative to the VFDecrypt Key exactly for iPhone 4S iOS 5.0.1 and 038-3763-001.dmg image. Source is theiPhoneWiki
Wait until the process terminates (You'll see a new prompt line)
Open (mount) decrypted.dmg (double-click it) and here it is the iPhone 4S root file system.
Navigate into the folder
/System/Library/Caches/com.apple.dyld
Make a copy of the (only) file dyld_shared_cache_armv7 (i.e. on your desktop) and rename it to dyld_shared_cache_armv7.new
Copy it (I used DiskAid) into your iDevice file system at the path
/var/spire
Navigate into that path (I used iFile Cydia App directly on my iPhone) and rename the original dyld_shared_cache_armv7 in dyld_shared_cache_armv7.bak. Rename now the recently copied dyld_shared_cache_armv7.new in dyld_shared_cache_armv7. Check that the new dyld_shared_cache_armv7 has the same properties than the dyld_shared_cache_armv7.bak (I had to add the execute property to the new file), than delete dyld_shared_cache_armv7.bak (I suggest also to backup that file before deleting it in case of problems).
Save, exit iFile, unplug from your Mac and reboot your device.
Reopen XCode and plug your device in. It probably won't be automatically detected. In this case open the Organizer (Window -> Organizer) and delete the current iPhone (or iPod touch, or iPad) profile (mine one had the the yellow light instead of the green one near the name), unplug it, reboot Xcode, reopen Organizer and wait your device profile auto installation process.
NOW your device should be fully working debugging your Apps! My iPhone 4 GSM iOS 5.0.1 JB with Spire installed does.
Hope this guide will help whoever have the same problem.
Thanks again kexik for his suggestions!
Find an ipsw for which there is the decryption key. Then uzip that ipsw and search iphone wiki for that particular firmware - there you will find a key as well as the name of .dmg file with root filesystem. Extract that dmg (using vfdecrypt or dmg decryptor) in extracted filesystem look for /System/Library/Caches/dyld.../dyld_shared_cache and copy that file to the place on the device I mentioned.
Sorry for not giving exact instructions, I wrote it from my memory. If needed, let me know and I will prepare more exact step-by-step. ;)
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 am compiling an IPhone application via command line (so no XCode options involved) and I am unable to get my symbol names to show when profiling with Instruments. I have tried several flags such as -gdawrf-2 and -g without any success. I have also tried using dsymutils to generate a .dSYM file but i have no clue how I'm supposed to use it so that failed aswell.
Any help will be greatly appreciated!
I Changed my project settings to not include the dSYM file while building:
Changing it to include the dSYM File helped the profiler desymbolize the symbols and fixed my issue:
I was still having issues with this.
My issue was I was able to see the dSYM file being generated, but Instruments wasn't picking it up.
To fix this, do the following:
Locate your dSYM file (should be in ~/Library/Developer/DerivedData/APP_NAME-XXXXXXX/Build/Products/[BUILD_TYPE]-[DEVICE-TYPE]/
With Instruments stopped, click on File -> Re-Symbolicate Document
Scroll down to the entry with your app name
Click "Locate" and choose the folder from step 1
Click the Start button to begin profiling
How Instruments obtains debug information:
Instruments obtains debug info from a .dSYM file which is normally generated automatically by XCode when setting Debug Information Format to DWARF with dSYM File combined with a checkmark in the Generate Debug Symbols option box. Setting these options will add an extra step to the XCode build process and generate a dSYM file after the application has been compiled. Every dSYM is built with a UUID that corresponds to a UUID in a Mach-O section in the binary that it's derived from. A Spotlight importer indexes the UUIDs of every dSym file that is in a Spotlight-accessible location on your Mac. Therefore SPOTLIGHT does all the black magic and is responsible of making the link between the .app you are running and its corresponding .dSYM file.
How to generate debug information and dSYM file without XCode:
Make sure you are compilig with –gdwarf-2 and -g flags. (Other flag combinations might work)
-g
Produce debugging information in
the operating system's native format
(stabs, COFF , XCOFF , or DWARF 2).
GDB can work with this debugging
information. On most systems that use
stabs format, -g enables use of extra
debugging information that only GDB
can use; this extra information makes
debugging work better in GDB but will
probably make other debuggers crash or
refuse to read the program. If you
want to control for certain whether to
generate the extra information, use
-gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below). GCC allows
you to use -g with -O. The shortcuts
taken by optimized code may
occasionally produce surprising
results: some variables you declared
may not exist at all; flow of control
may briefly move where you did not
expect it; some statements may not be
executed because they compute
constant results or their values were
already at hand; some statements may
execute in different places because
they were moved out of loops.
Nevertheless it proves possible to
debug optimized output. This makes it
reasonable to use the optimizer for
programs that might have bugs.
-gdwarf-2
Produce debugging information in DWARF version 2 format
(if that is supported). This is the
format used by DBX on IRIX 6. With
this option, GCC uses features of
DWARF version 3 when they are useful;
version 3 is upward compatible with
version 2, but may still cause
problems for older debuggers.
Generate a dSYM file using dsymutil. If the tool isn't recognized in command line, use spotlight to find it.
IMPORTANT: Place .app file on your mac HD before you generate the dSYM if you are working on a networked drive.
dsymutil MyApp.app/MyApp -o
MyApp.app.dSYM
Place the .dSYM file on the mac's local drive and run Instruments as you normally would.
Resettig spotlight's indexing:
If symbols aren't shown, it might be because spotligh is bugged. You can try reseting spotlight's indexing by adding your folder containing the dSYM file (or even your drive) to the “Prevent spotlight from searching these locations” in the spotlight preferences and then removing it right away.
In Xcode 4.5 you can choose to Profile from Debug or Release builds. Release defaults to stripping the symbols when copied to the device. It's very easy to switch to the Debug configuration for profiling without breaking your release configuration. To do that, select Product -> Edit Scheme from the XCode menu. Select "Profile" from the list of schemes that comes up, and then select the correct Build Configuration for that.
Or you could make a separate release/profile configuration and use that in your Profile section of your scheme. How to add a separate build configuration is described in the XCode User Guide.
With Xcode 6 Instruments you can provide dSYM file as follow:
File -> Symbols... menu (when profiling is stopped)
select your app and press Locate button
select path which contains dSYM (usually ~/Library/Developer/DerivedData/APP_NAME-XXXXXXX/Build/Products/[BUILD_CONFIGURATION]-[TARGET_PLATFORM]/). Tip: You can copy this path from terminal and use OS X shortcut ⌘+SHIFT+G in dialog.
Also Instruments will ask you if it should use selected path to try load dSYM for this app in the future. Answer Yes :)
Spent three days trying to figure this out for Xcode 7.1/7.3...
Changing the deployment target to the latest version (9.3 at the time) fixed this issue for me. My company targets 7.0 so I will probably have to create a custom Scheme for profiling the code in Instruments to avoid having to change the target (or forgetting to change the target) when we do a production release.
Seems like it's probably a bug if dSYMs fail to work based on the deployment target?
The problem is that spotlight cannot find the .dSYM files.
This is because Apple changed the location of the DerivedData folder.
The DerivedData now goes in ~/Library
Spotlight will not index ~/Library and as far as I have been able to establish, cannot be made to index it either (e.g. mdimport is ignored).
A work around to get symbols in your profiler, is to simply copy the data outside ~/Library e.g. your home directory will do fine.
I used this command line:
$ cp -r ~/Library/Developer/Xcode/DerivedData/AppName-xxxxxxxxxxx/Build/Products/Release-iphoneos/ ~/
When you kill your profiler, and start a new profile run, you will see that the symbols are available again.
Check the build log and make sure that your -g switch is getting through to the compiler - it's easy to get this wrong when changing settings at the project and/or target levels for different build configurations etc.
Another work around in the version of Instruments that comes with Xcode 4 is to use the Re-Symbolicate Document menu item under the File menu for Instruments. This menu item to allows you to use the symbols located in the .dSYM file in ~/Library/... directory.
In my experience, this is usually because "Profile" has been called before the most recently modified version of the app has been installed on the target device.
Try running the app on the device/target, then calling "Profile" again after it has been reinstalled.
I got this problem because the XCode project was on a network share where Spotlight wouldn't find the dSYM files. Make sure it's on the local drive.