I am using Bitrise as a CI/CD on my iOS app.
In the workflow there is a step to release the app via Fabric.
When a crash happens the only think I can see in the Dashboard is many __hidden steps on the stack.
I guess that this is because of some missing symbols but Fabric doesn't says that any symbol is missing. I tried to add them manually any way but I am still seeing the __hidden crashes.
Any ideas of how can I fix this issue?
Here is an example of what I get.
Check out Apple's document describing hidden symbols. Look for the "Translating 'hidden' symbol names back to their original names" section.
The issue here isn't that Crashlytics is missing symbol information. It's that the symbol information they have literally tells them your symbols are named __hidden#xyz. This has resulted in obfuscation you are seeing here. As the Apple doc describes, it is possible to de-obfuscate these symbols, but I'm not sure if Crashlytics supports this. They have a little bit of info here.
My understanding is this happens when you opt to not share symbol information with Apple during the app submission process. If I'm right, once you do this, it is impossible to change until you release a new version of your app.
Update:
I've discovered an option in dsymutil that makes it possible to deobfuscate a dSYM in this situation.
--symbol-map=*bcsymbolmap*
This will modify the dSYM in place with deobfuscated symbols. Uploading that dSYM to Crashlytics should result in expected symbolication. However, due to caching, you will probably need to reach out to them first to make sure this change takes effect.
Related
I've been investigating the crash in our app for quite a while, and I still can't figure out why Crashlytics cannot symbolicate some of the crashes (3 to be specific). These are actually the current major crashes of the app and we are desperately looking for any hint possible.
Our app has bitcode enabled and opt-in uploading dSYM to Apple. I tried to read through the Crashlytics doc All about Missing dSYMs, manually download the dSYM zip from iTunesConnect, uploaded it to fabric. The "hidden" crash number keeps growing afterwards, and the problem is, we never get a missing dSYM warning in fabric and it's not showing the dSYM missing in the fabric settings page for the app build we are trying to investigate.
The stack trace is like this:
Crash stack trace
Any helps and suggestions would be very much appreciated! Thanks!
I can't tell you why the symbolication failed. But from looking at your crash report, a few things come into my mind, maybe they can help you somehow.
The crash happens inside a closure which uses UIWebView somehow. After doing something with javascript, resources are being freed, this is then when the crash happens. You can check the last code called here:
https://github.com/WebKit/webkit/blob/f43689c3ed50cd00bf76d5731983046b988e6efa/Source/WebCore/loader/cache/CachedResource.cpp
Nothing fancy going on there.
My guess is, that input vars of the closure are freed to early. Even if you are blind, without a working symbolication, you could try to find closures initiating JavaScript calls and check for this conditions e.g. [unowned self] in or similar and try pass them in owned. This could obviously lead to leaking memory, but you can test this before releasing.
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.
Preface: I am not an iOS developer and relevant documentation is scarce, so I may be missing something that should be obvious.
My team is building a Firebase app for iOS in Swift and we're getting crash reports in the console with obfuscated stack traces. The provided instructions to upload symbol files don't seem to be correct - the command as written returns an error about missing service account, and after we figured that one out it gave more warnings that we didn't decypher - but we managed to configure automatic upload and then rebuilt the latest release.
Now I see that a handful of UUIDs (presumably the phones/sims that we've run that rebuilt version on?) have uploads associated with them, but none of them match the reports we've received. What I don't understand is how we're supposed to generate symbol files for the rest of the UUIDs. Am I correct in understanding that a UUID refers to a specific device, and any given symbol file will match only a single build and UUID? We don't have access to the devices that are reporting these crashes; that's why we're relying on the console instead of debugging them in Xcode. If you only get the correct symbols for the devices that you physically connect to Xcode when you make the build, what's the point of getting the stack traces online?
I'm not sure why Crashlytics didn't show me where is the line crash
i have follow all the integration instructions and read the documentation but still no result
and i'm sure that i've been upload the right dSYM file
its just showing me something like this screenshot
and i've been looking around and they said to do this
but it doesn't help
any idea?
This is a known issue that happens with some bitcode enabled apps. It seems to be a bug with how Apple is regenerating dSYMs and we've (Fabric) submitted a report to them about it.
In the meantime, if you turn off bitcode and rebuild then you should be all set for future crashes.
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.