Unknown crashes in Firebase Crashlytics console #4327
-
|
Hi there, Let me know if this is not the right place for this message. :) They're not tied to any specific Android version or model, here are the average stats:
The stacktrace is not readable at all, is it a misconfiguration of Firebase? We have correct stacktraces for other more common crashes. Maybe it's NDK related? Here are examples of stacktraces: Current configuration is React Native 0.62.2, no hermes, rnfirebase 8.2.0 / rn-firebase crashlytics 8.1.2 Thanks for your help 🙏 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
Things like that are really frustrating aren't they? I have an Android native app with 1.7MM users (AnkiDroid, open source flash cards so it's worth precisely $0 but makes for good knowledge of Android crashes) and you wouldn't believe the stacks we get in Chrome, it manages to fail in endlessly surprising ways. That's what these stacks look like to me mostly - the base.apk and chromium ones at least. libjsc is crashing in the JSC javascript interpreter used by react-native but it's native - it's not a coding error on your part. There's nothing you can do about the stacks being not-understandable unless you turn on NDK crash support for crashlytics but that's very hard to do because then you have to provide paths to the stripped and unstripped native libraries, and you don't get access to those for Chrome so it doesn't help. My biggest advice is to update to current stable in case the JSC has improved (or perhaps try swapping in V8 or Hermes - latest Hermes works with RNFB from what we understand) and be careful with your memory usage - use the Android native profiler to make sure you aren't loading huge bitmaps and fonts and things as that's a classic crasher, and especially if you do so in WebViews. Sorry this is vague but I have had the same experience of receiving these stacks and there isn't much actionable unfortunately unless you can get a reproduction case, and even then it's mostly so you can implement a workaround. |
Beta Was this translation helpful? Give feedback.
-
|
They are frustrating! 😉 Thanks for your insights, that's cool to know I'm not alone with these crashes :) Apparently the looks of the stacktraces might be because we enabled Android App Bundle. https://stackoverflow.com/questions/55966582/google-play-crash-logs-not-symbolicated-with-android-app-bundle Will update RN and JSC, or test Hermes, thanks! |
Beta Was this translation helpful? Give feedback.
-
|
They push app bundle pretty hard and yes, it has similar problems to "bitcode-enabled" iOS builds in that it re-munges your so unless there is a way to then download (from Google Play) and upload (to Google Firebase) the new symbol tables I'm not sure there's anything you can do. We still use APKs with ABI splits in the app I mention and get worthless symbols for Chrome crashes anyway, for what it's worth :-) I wouldn't skip the Android Studio profiling step and hunting for a real reproduction - for the few crashes that were attributable to our use of WebView for instance, we did find a reproduction in form of loading a very heavy CJK font in combo with images exhausting memory, and we found that implementing the WebView termination handling API was a big improvement: https://developer.android.com/guide/webapps/managing-webview#termination-handle / https://github.com/react-native-webview/react-native-webview/blob/master/docs/Reference.md#onRenderProcessGone |
Beta Was this translation helpful? Give feedback.
-
|
(I am making the assumption that with lots of Chrome crashes you are using a WebView, and that it's crashing - I'll also mention I understand those are assumptions and if I'm not correct there then go ahead and ignore the suggestions based on them of course, they'll be ineffective) |
Beta Was this translation helpful? Give feedback.
Things like that are really frustrating aren't they? I have an Android native app with 1.7MM users (AnkiDroid, open source flash cards so it's worth precisely $0 but makes for good knowledge of Android crashes) and you wouldn't believe the stacks we get in Chrome, it manages to fail in endlessly surprising ways. That's what these stacks look like to me mostly - the base.apk and chromium ones at least. libjsc is crashing in the JSC javascript interpreter used by react-native but it's native - it's not a coding error on your part.
There's nothing you can do about the stacks being not-understandable unless you turn on NDK crash support for crashlytics but that's very hard to do because then …