-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIGSEGV hermesFatalErrorHandler -- Out of Memory (OOM) #439
Comments
I think the symbolicated stack trace is not correct, specifically the following lines:
There's no way for |
Other than that though, the main caller of Unfortunately, I just realized that there actually isn't any logging hook attached! So it'll just segfault without putting the message anywhere. I'll make a commit to fix that, and will try to pick it into RN 0.64 if possible. Going off the assumption that this is an OOM, the way to fix this is to identify what surface your users were using before or during the crash, and find out if they are using too much memory. The best way to identify what memory is being used is with Hermes heap snapshots and the heap timelines. You can follow the tutorial to attach a JS debugger to Hermes here: https://reactnative.dev/docs/next/hermes#debugging-js-on-hermes-using-google-chromes-devtools. Once you've done that, use the memory tab to take heap snapshots and heap timelines to see where memory is being allocated. |
|
I landed a fix for the missing fatal message with facebook/react-native@291cc95 in the React Native repo. |
@MayoudP it's hard to tell just based on that stack trace what the issue could be, or if it's even calling |
We started seeing this also production only in our latest release this week. Our version of RN and Hermes (0.63.4) didn't change in this release 0.5.0. No changes to our RN version (0.63.4) and version of Hermes.
|
Hi @smacgregor, unfortunately an unsymbolicated stack trace doesn't mean much to us, since we have no idea where in As I mention above, the most common cause of a I recommend trying to identify any memory issues using the Chrome memory tools with Hermes as I detail in an earlier comment. Fixing those will reduce crashes and improve the performance of your app. |
Thank you @dulinriley here is the symbolicated stack trace. Will spend more time with the memory profile tools - it's a strange crash in that our users seem to only hit it one time but almost everyone is hitting it one time.
|
Unfortunately I don't think the stack trace was symbolicated correctly, in particular from this snippet:
|
Thanks again - I believe this one is symbolicated correctly:
|
Unfortunately @smacgregor I think that's still an incorrect stack trace. In several places it shows
With all that I might be able to see what's going wrong |
Thanks again for your help @dulinriley. I think the problem with the bad symbolication came from our app using a version of the NDK (r15) which couldn't symbolicate arm64. RN 0.63.4 Running this again using ndk-trace from the latest version of the ndk:
Output
|
Thanks @smacgregor that stack trace now looks right. At frame 5 we can see |
This is the issue and comment where I'm trying to pick in the improved crash message: |
Thank you - we were able to track down the offending code change that was triggering this OOM. I'm anxious to see your fix for improving the crash message go out - I think that will help us spot the culprit faster if it happens again in the future. |
Bug Description
We are getting a lot of crash reports in Google Play/Bugsnag and I'm having a hard time finding out what could be the next step. The app is crashing for almost all Android versions, not specifically at startup. This is happening with Hermes 0.4 & 0.5.1. Our app is open-source https://github.com/standardnotes/mobile. Is there anything more I could provide? Unfortunately I have not been able to reproduce this locally yet, and neither Google Play/Bugsnag provide a more extensive stack trace.
Hermes version: 0.5.1
React Native version (if any): 0.63.4
Android version (if any): all
Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64):
I also tried to symbolicate it using the unstripped libraries:
The text was updated successfully, but these errors were encountered: