Crash in RN debug mode #26
Comments
|
This crash ("Too many handles allocated in GCScope") is an assert we have enabled in the native code of Hermes, and its purpose is to find problems where Handles are allocated in loops: Native code is supposed to either make a new GCScope, or use a "marker" and flush it every loop iteration, like so: In order to fix this, we need to know what the native stack looks like. |
|
Encountered same problem here, using RN |
|
@RageBill, @mjmasn since you can reproduce the problem, can you try to attach a debugger and get a native (C++) stack trace? Android Studio has lldb support (for example). Once we have that stack it will probably be a trivial fix. |
|
Hello @dulinriley. I hope the stack trace below helps you. tgkill 0x0000007fb2680838 |
|
@HeribertoAlves that’s actually a different crash (due to a non-ASCII character in a string that says it should be ASCII). Can you file a separate issue for that and include that stack trace? |
#47 done! |
|
After I have removed usage of |
|
@RageBill unfortunately I'm still not sure of what native function in Hermes the assert happens in. Also,
To be clear, is this the same assert? "Too many handles allocated in GCScope" One thing you can try is the tool |
|
@dulinriley I tried looking at the link you provide me, but I could not locate this part in my React Native project: "-sym $PROJECT_PATH/obj/local/armeabi-v7a". Could you suggest in which folder should I be looking? I have searched through my project directories and I don't find anything similar to /obj/local/armeabi-v7a. |
|
Does I'm not sure where However, I bet what Android is looking for is some |
Summary: We're listed in JCenter now, so the separate repo is no longer necessary. Pull Request resolved: facebookincubator/fbjni#26 Reviewed By: mhorowitz Differential Revision: D18743781 Pulled By: passy fbshipit-source-id: 74a0c5badf910761ebc438d528106732914344c9
|
Hi @dulinriley! I'm also facing a crash only when hermes is enabled in React Native 0.62.rc-2 However, I can only see one error log and there's no other stacktrace: How could I debug what went wrong concerning this? Thanks! Related issue: wix/react-native-navigation#5964 |
|
+1 same error here in RN 0.62.2 . |
|
Unfortunately we don't have a good way (yet) to symbolicate our crashes in native code without building Hermes from source. We have an open issue for figuring out how to make that work: #119. |
|
I experience the same kind of errors Only happens on release build type. When data is loading the first time in a FlatList. Relaunching after a crash works fine. With this associated ndk-stack. Does it help ? |
|
@nikosmonaut unfortunately I don't think that stack is symbolicated correctly. These three frames: Can't possibly be in this order. This is the body of There's no way for that to call any function. This may have been symbolicated with the wrong version of Hermes, since the functions are all from Hermes, just maybe slightly offset from the true functions. |
|
I builded hermes from sources and found these unstripped libs under $HERMES_WS_DIR/hermes/npm/android/unstripped-($BUILD_TYPE)/0/lib/($ABI)/libhermes.so to use with ndk-stack. But I'm not really sure if these ones are the correct to use |
|
@nikosmonaut if you built from source, and used those same artifacts to run the app, it should work to symbolicate. At that point the logs should be completely symbolicated without needing to use ndk-stack. |
|
@dulinriley thank you for your explanations. It all became clearer now. Last time I tried an unstripped lib from master with a v0.5.0 version on app. So it obviously couldn't match. I think the build is broken on 0.5.x versions. I had to include a lib here to make it work I tried two versions v0.5.0 and v0.5.1 and have the same error. ndk crash dump |
Thanks for pointing that out, I believe it's an issue with using the GNU STL as opposed to the libc++ STL. We'll make a patch for that. As for the SIGSEGV, looks like it's happening here: and column 48 is the "i" in "index". So getting the start of a heap segment from a pointer in the heap is giving us a wild address. Even more interesting, this stack trace is the constructor path for a BasedPointer, and is coming from a FullMSCUpdateAcceptor pass. Is this easily reproducible? We're going to need to debug this and find out exactly where the bad pointer is coming from. |
|
Yes it is easily reproducible yet I'm trying to narrow the code but no luck. Edit: Finally I found what caused the fatal. But can't reproduce it on a test repository. It is a little similar to this one. Somehow scrolling a flatlist after calling a async function crashes the app. If it's a normal function everyting is ok. And no crash with JSC. |
|
I'm going to close this issue, because I believe multiple distinct crashes have become aggregated here. I'm also going to lock this issue, to encourage users seeing crashes to make a new issue with fresh information, and avoid aggregating multiple crashes here. |
|
See #383 for further information on the segmentIndexFromStart crash |
Appreciate this report probably isn't too helpful as I don't have a repro I can share, but I wanted to ask what's the best way to debug an issue like this?
Crash happens in debug mode, React Native 0.60.3, Samsung Galaxy S9+. Context-wise, I suspect this is happening when loading 'db' files for
react-native-local-mongodb(~15 files, tens to hundreds of lines per file, each containing a stringified JSON object).Aside from that, Hermes seems significantly slower than JSC in debug mode (maybe 3 or 4x slower, stuff like switching routes with
react-navigationtakes a few seconds), is that expected at this stage? Could that be to do with the amount ofconsole.log-ing we do, I know that's a big issue with JSC on slower devices.In release mode, the app startup is significantly faster with Hermes and general performance seems similar to JSC so it would definitely be nice to make the switch in future 👌
The text was updated successfully, but these errors were encountered: