I know that dSYM files are useful to have when you generate the final version of your app for the app store, because they will have the debug symbols that are used to symbolicate the crash log.
My question is if they are necessary during develop time. I ask this because by disabling them compiling time drops by 75%.
First off, to avoid some confusion: the default debug info format for the Debug configuration for new iOS projects is "DWARF with dSYM file", but for new OS X projects is just "DWARF".
Part of this is historical, but at present, the iOS setting is still "DWARF with dSYM file" only because the part of Xcode that symbolicates crash logs as they are copied off iOS devices uses the dSYM for that purpose. So if you are planning to test your Development build downloading it to the device, and then finger-launching and exercising it outside the debugger, then having the dSYM is handy for understanding any crashes you run into. If you're running under the debugger, of course, it will just stop at the point of the crash, so you don't need to symbolicate a crash report.
Other than that, I don't think you lose anything switching to DWARF for iOS. And as SpaceDog noted, it does speed up turn around time since the debugger knows how to lazily link up what DWARF it needs, whereas the dSYM creation tool (dsymutil) has to read & rewrite it all.
Of course, when you do a Release build you want to make & archive the debug information - which is the whole point of the dSYM, since otherwise the debug information (contained in the .o files) will get deleted along with the other intermediate build products and you won't be able to symbolicate crashes that happen in your released app.
You only want DWARF for development and DWARF with dSYM for release.
A new project comes defaulted to this configuration>
Also See this SO Answer.
Related
Question #1:
I am using Crashlytics for one of my commercial iOS Apps. Their service seems very helpful. I wonder if there is any Legal issue of using their services for commercial apps? Is there any limitations for using Crashlytics?
Question #2:
I need to upload .dsym file in their server to get crashlogs symbolicated. Is there any privacy issue. Is it possible to get my code (or any info) back by reverse engineering when they have .dsym file.
Question #3
Sometime some crashes are not showing in the crashlytics dashboard. Is it necessary to be online when crash happens to get crashlog in dashboard? Don't Crashlytics keep logs trace when offline and send logs back to the server when device become online? Any idea how they work?
Mike from Fabric here, but I'm not a lawyer.
1) Fabric and Crashlytics is used in many commercial apps, including our own. There aren't limitations to using Fabric. You can find the Fabric terms of service here.
2) The dSYM is what let's us or any other crash reporter symbolicate the crash report as it contains the symbols that map back to your app's source. None of your source code is uploaded. From Apple's own documentation:
As the compiler translates your source code into machine code, it also
generates debug symbols which map each machine instruction in the
compiled binary back to the line of source code from which it
originated. Depending on the Debug Information Format
(DEBUG_INFORMATION_FORMAT) build setting, these debug symbols are
stored inside the binary or in a companion Debug Symbol (dSYM) file.
The Debug Symbol file and application binary are tied together on a
per-build-basis by the build UUID. A new UUID is generated for each
build of your application and uniquely identifies that build. Even if
a functionally-identical executable is rebuilt from the same source
code, with the same compiler settings, it will have a different build
UUID.
3) Crashes are caught regardless if the app is connected to a network or not. However, crashes are only sent on relaunch of the app and would then be processed.
One thing to note is that if you're testing in the Simulator or with your device connected to Xcode will cause Xcode's debugger to capture the crash instead of us.
Further, if the dSYM hasn't been uploaded, then we're unable to process the crash report and we'll alert you in the Crashlytics dashboard of the missing dSYMs so that you can upload them.
Started using Crashlytics and am curious why only the DSYMs have to be uploaded and not the full .app binary to match. I was under the impression that to symbolicate you needed a binary with matching DSYM file. Is that not the case? Basically trying to figure out the magic of how Crashlytics symbolicates when all I do in my app is run the post-build script that uploads the DSYM
Mike from Fabric and Crashlytics here.
A dSYM file actually contains all the debug symbols of your app needed to symbolicate the crash report. This is why we recommend having your Debug_Information_Format set to "Dwarf with dSYM". We also generate a unique build id so that even if the build and version number don't change, the dSYM uploaded for that build remains accurate for any crash reports that need to be symbolicated.
You can also read more information on this from Apple, but the most important part is this: "As the compiler translates your source code into machine code, it also generates debug symbols which map each machine instruction in the compiled binary back to the line of source code from which it originated. Depending on the Debug Information Format (DEBUG_INFORMATION_FORMAT) build setting, these debug symbols are stored inside the binary or in a companion Debug Symbol (dSYM) file."
As noted above, the symbols can be in just the dSYM file, hence our recommendation for the setting of Debug_Information_Format.
I've Googled this extensively, and either the situation someone's experiencing involves a different Xcode version (and therefore different build options), or a presence of a dSYM file.
So, here's the situation. I received a crash report through Xcode. It's just memory addresses. Trying to open it in project gives me the same memory addresses. Thought about manual symbolication but for that I need my dSYM file corresponding to the archive I built. But when I 'Show package contents' for the archive I built in finder, its dSYM folder is empty.
My Xcode settings at the time of archiving were:
DEBUG_INFORMATION_FORMAT: DWARF with dSYM File
STRIP_INSTALLED_PRODUCT: Yes Switching to No makes no difference.
DEPLOYMENT_POSTPROCESSING: No Switching to Yes makes no difference.
Also, I selected 'Include symbols' when uploading the archive to iTunes Connect.
The process for deployment with Apple is confusing-as-hell enough, without having to worry that when a crash does happen, the resport is in fact readable!
So my questions are:
1) Why was my archive missing a dSYM file?
2) If the dSYM file would've been generated, where could it be?
3) If I really do not have a dSYM file, can I still somehow get human-readable symbol names? I've got the original archive I uploaded and access to source code for that build.
3a) If I Product>Archive again (and assuming this time a dSYM does get generated), can I use this dSYM file instead? Or will it have a different UUID, causing it to be incompatible with the crash log cause...well...Apple?
Xcode version: 6.4
Here's what my crash log looks like in Xcode Organizer:
Thanks.
EDIT:
I upgraded to Xcode 7.3 before trying this but it may also work for version 6.
The solution to question (1) is to set the following in project build settings:
GCC_GENERATE_DEBUGGING_SYMBOLS
On XCode 8.3.2, select Yes on Generate Debug Symbols
For question 1), I also don't know. It may be a bug of Xcode. You can archive
the same code again, then generate a same dSYM file.
For question 2), you can search 'dSYM' in the folder '~/Library', because 'dSYM' file output in there generally. If not found, try searching it in the entire disk.
For question 3), you must have the system library symbol file that the crash log listed in 'Binary Images' section. You can find it in '~/Library/Developer/Xcode/iOS DeviceSupport'. If not found, you can connect an iPhone with the same OS version showed in the crash log to Xcode. After Xcode finished processing it, the system library symbol file of the iPhone can be copied to the folder. Then, you can re-symbolicate the crash log.
For question 3a), For the same app code, different Archive may be have a different dSYM file(UUID). If you use it to symbolicate the crash log, the symbolicated crash line is very close to the real crash line, so this can also help you to infer the real cause of crash.
From your screenshot, there only one line from your app code not be symbolicated. Now, you can generate the dSYM file of your app through using the app code which causes the crash to archive again. After you generate the dSYM file, use command line dwarfdump -u yourApp.app.dSYM to get UUID of it,Then check the uuid if contained in the first line of 'Binary images''. If NO, you can modify the UUID in the first line of 'Binary images'' to same as the new UUID which got from dwarfdump -u XXX.dSYM, Note the cpu architecture. Finish this, you can re-symbolicate the crash log in Xcode, or use command line symbolicatecrash crashreport.crash yourApp.app.dSYM. Note, you must guarantee the version of your app code same as version in the crash log, if not, the result is unbelievable.
I've been getting a bunch of crash logs for my (largely c++) app on iOS. My problem is I can't seem to ever symbolicate these crash reports properly.
What is the "proper" setting for stripping debug symbols for release on iOS? I get that you'd want to strip the debug symbols so the download size of the app isn't ridiculously large.
But the problem is that it seems to make the crash reports virtually unreadable.
Do dSYM files on the xcode archives get sent and eventually downloaded by the users?
Or is it simply something to be kept for future symbolicating purposes (done locally on my own machine, on xcode)?
Or is it simply something to be kept for future symbolicating purposes (done locally on my own machine, on Xcode)?
This. Your "release" config (or whichever config you use for distribution) should have the following setting:
Symbols Hidden by Default: Yes
Xcode will still generate a dSYM folder which is what you will use for symbolicating crash logs. There are 3 ways to handle symbolicating:
Use Xcode. For this you need to use the Product -> Archive feature whenever you release. Once an archive is created, you can select "Export" then "Save for iOS App Store Deployment". After this you can drag crash logs into the left side of the "Device Logs" window and Xcode will symbolicate them for you.
Manually symbolicate using the symbolicatecrash tool located inside your Xcode.app folder. This is useful if you've released code to users but don't have an Xcode archive. You need to be sure that the crash log matches the binary and dSYM or it will not work.
Use a third party tool that collects crash reports and symbolicates them for you. Examples include Crashlytics, Bugsense, or HockeyApp.
There is a build setting that says "Symbols Hidden By Default" that I have set to NO on my Debug build, but I'm still not getting symbolized crashes on my devices. Is this just not possible on ios ?. I know that on mac it is, but maybe there is another setting I'm missing ?
Thank you.
Symbolication will only work, if you did not start another build process after deploying a build onto your device. Each build will generate a unique combination of app binary and dSYM file with the same UUIDs. This ID is set in the crash report and used to find the correct dSYM to resolve the symbols in the crash report.
If you build again, these files get replaced and because of that get a new UUID also. So the symbolication process can not find the corresponding files and will not resolve the app specific symbols. The iOS symbols should work fine though.