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.
Related
I have been observing this that when ever my app crashes i get the crash log and try to symbolicate it but following happen
When I use xcode to symbolicate, it never symbolicates the addresses of the crash
When I use atos command specified developer.apple.com technotes it either gives some other class function name that does not have to do any thing with the crash
I have used other methods like symbolicatecrash script but the result is same as before.
I also tried solution given stackoverflow.com/questions/7932992 but did not succeed
I created a demo crash and tried to change my scheme of the app for "Run" and changed "build configuration" to "release" to check if the crashes symbolicate when I run the app directly to device, I test the app, the demo crash occurs and in this case the crahes get symbolicated.
I created a demo crash in a new app and created an archive and export IPA, used this ipa in a device to recreate that crash but still xcode could not symbolicate that crash.
I don't get why is it behaving this way,
I looked into the archives to find my dSYM file and can locate it there but could not symbolicate it using any of the processes stated above.
A guidance will be helpful!
I was working with code back to see if there can be any impact of bitcode with help of a friend, found that while exporting archive to IPA, it asks me to rebuild with bitcode (which was checked) I just tried and unchecked it to create the IPA and this time my app crash logs were symbolicated, I still don't know why this happens because apple recomends to rebuild with bitcode while submitting apps.
I am looking for more answeres for why is it happening?
Will keep you posted (also a enlighten me if there are any misses.)
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 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
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.
I m having some problem with my app which reproduces only when i install it ad hoc, but doesn't reproduce if i just run the app from Xcode. I would like to debug this problem, but so far i m not having any luck. I m using Xcode 5.1.1. Here is what i did:
1) Go to Product->Scheme->Edit Scheme->Archive and set build
configuration to Debug.
2) Code signing identity is set to iPhone Developer.
3) Generate Debug Symbols is set to Yes.
4) Go to Product->Archive and after it is archived, click
"Distribute", then choose "Save for Enterprise or Ad Hoc Deployment".
5) My development provisioning profile is selected.
6) Click "Export" and export the .ipa file.
7) Use iPhone configuration Utility to install the app onto the
device.
8) Run the app on the device.
9) In Xcode, go to Debug->Attach To Process->By PID or Name, enter the
app name. Xcode attaches successfully and says running the app on
iPad.
10) However, i cannot hit any breakpoints which should be hit when i
do certain actions in my app (if i install and run the app from Xcode
instead, all breakpoints are hit).
Am i missing something?
You don't have any debug information for the app at this point, and since most apps are pretty thoroughly stripped, there won't even be symbols for lldb to hook on to. So we're not going to be able to successfully set breakpoints.
When you built the app, Xcode produced a dSYM file (MyApp.app.dSYM) which has the debug info in it, so all is not lost. Problem is when you attach to some - to Xcode - random app on the device, Xcode has no way to know where to find its debug info.
You can add the debug info into your debug session in lldb by using the command:
(lldb) add-dsym <PathTo.dSYM>
You have to do this after you have attached.
lldb also uses SpotLight to find dSYM's so if you put the dSYM somewhere that SpotLight knows to search (like your Desktop or a folder under your User directory) then lldb should pick it up automatically.
You can tell whether lldb has successfully read in the dSYM by doing:
(lldb) image list <AppName>
If lldb found the dSYM, it will list the path to it on a separate line after listing the path to the AppName binary.
Jim Ingham, thanks for your answers.
I found the reason why i was unable to debug into static libraries. In each Xcode project, there is a setting called "Strip Linked Product" under "Deployment" section. In all my projects this setting was set to "Yes".
In order to debug into static libraries for an app built by archiving, i set this setting to "No" in each dependent library project (as well as the main project). This can also be set differently for Debug/Release modes. After this, i see the library symbols built during archiving and i m able to debug into library code. I hope this helps someone.
Unfortunately (or maybe fortunately) the bug i was trying to debug no longer reproduces when the library symbols are not stripped. Maybe something happens when the symbols are stripped, i will need to investigate further.
I was struggling with the same problem, and just launching my app from Xcode was not an option - I had to build the IPA, sideload it on an iOS device, and then debug. Eventually I was able to make that work with the following steps:
1) Set the scheme archive target to Debug
2) Change the following settings for the Debug builds
Keep Private External Symbols (KEEP_PRIVATE_EXTERNS) : YES
Enable Bitcode (ENABLE_BITCODE) : NO
Strip Linked Product (STRIP_INSTALLED_PRODUCT) : NO
3) Rebuild, archive, and deploy the resulting IPA file to your iOS device.
4) Launch the app, and in Xcode, select Debug/Attach to Process/YourAppName(id)
5) Break into the debugger - you should be able to see the code, put and use breakpoints, etc.
If you want to debug your code from the very beginning, just put a loop that sleeps for a second or two and then checks a flag at the top of your main function - when you break into the debugger, just change the flag to let it escape the loop.