hermes: Hermes + JNI crashes on jsi::Function::call
Bug Description
Hello. I’ve encountered some crashes and have no idea how to deal with them. Basically what I have is something like this(c++ pseudo code):
jsi::Function* f = /*...*/;
try {
f->call(rt, static_cast<const jsi::Value*>(args), (size_t)params.size());
} catch(...) {
// handle an error
}
The problem is if there is an error inside the f function then the c++ error is not handled properly and passed to the catch but instead, the app crashes.
What also happens here is: the whole code is run inside a block which is passed to java via jni and called there. Everything works fine if there are no errors inside called the jsi function.
As this works properly on JSC I assume the problem lies either in hermes or JNI or just in the way how all those components(hermes, JNI, jsi) work together.
The full code is available as it happens in open source and the place I’m talking about is here
I’m pretty sure this very line is causing problems as I tested multiple different scenarios and for me, it looks like the error handling is somehow broken 😞
Also, we use fbjni.
- I have run
gradle cleanand confirmed this bug does not occur with JSC
Logs
Here are the logs from android studio:
logs
2020-11-25 15:16:29.352 32407-32407/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: Build fingerprint: 'Lenovo/kuntao_row/P2a42:7.0/NRD90N/P2a42_S233_170404_ROW:user/release-keys'
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: Revision: '0'
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: ABI: 'arm64'
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: pid: 32167, tid: 32167, name: nimated.example >>> com.swmansion.reanimated.example <<<
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: x0 0000000000000000 x1 0000000000007da7 x2 0000000000000006 x3 0000000000000008
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: x4 0000000000000000 x5 4000000000000000 x6 0000000000808000 x7 7affff514b4f79fe
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: x8 0000000000000083 x9 ffffffffffffffdf x10 0000000000000000 x11 0000000000000001
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: x12 ffffffffffffffff x13 ffffffffffffffff x14 ffffffffffffffff x15 0000000000000000
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: x16 0000007f7b17fee0 x17 0000007f7b12982c x18 0000007f5f614be8 x19 0000007f7e5b2b40
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: x20 0000000000000006 x21 0000007f7e5b2a98 x22 000000000000000b x23 0000007f7e5b2b30
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: x24 0000000000000000 x25 0000007f5b3f5170 x26 0000007f7e5b2b30 x27 0000000000000000
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: x28 0000000000000000 x29 0000007fc4bcbc80 x30 0000007f7b126cbc
2020-11-25 15:16:29.353 32407-32407/? A/DEBUG: sp 0000007fc4bcbc60 pc 0000007f7b129834 pstate 0000000060000000
2020-11-25 15:16:29.358 32407-32407/? A/DEBUG: backtrace:
2020-11-25 15:16:29.358 32407-32407/? A/DEBUG: #00 pc 000000000006b834 /system/lib64/libc.so (tgkill+8)
2020-11-25 15:16:29.358 32407-32407/? A/DEBUG: #01 pc 0000000000068cb8 /system/lib64/libc.so (pthread_kill+64)
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #02 pc 0000000000024190 /system/lib64/libc.so (raise+24)
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #03 pc 000000000001cbac /system/lib64/libc.so (abort+52)
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #04 pc 000000000003ca80 /data/app/com.swmansion.reanimated.example-2/lib/arm64/libhermes-executor-debug.so (_Unwind_SetGR+16)
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #05 pc 00000000000b8550 /data/app/com.swmansion.reanimated.example-2/lib/arm64/libfbjni.so (__gxx_personality_v0+244)
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #06 pc 0000000000269e64 /data/app/com.swmansion.reanimated.example-2/lib/arm64/libhermes.so
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #07 pc 000000000026a36c /data/app/com.swmansion.reanimated.example-2/lib/arm64/libhermes.so (_Unwind_Resume+116)
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #08 pc 000000000002dc24 /data/app/com.swmansion.reanimated.example-2/lib/arm64/libhermes.so (_ZN8facebook6hermes17HermesRuntimeImpl4callERKNS_3jsi8FunctionERKNS2_5ValueEPS7_m+952)
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #09 pc 0000000000059c34 /data/app/com.swmansion.reanimated.example-2/lib/arm64/libreanimated.so
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #10 pc 000000000005f81c /data/app/com.swmansion.reanimated.example-2/lib/arm64/libreanimated.so (_ZN10reanimated9Scheduler9triggerUIEv+56)
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #11 pc 000000000002f394 /data/app/com.swmansion.reanimated.example-2/lib/arm64/libreanimated.so (_ZN8facebook3jni6detail13MethodWrapperIMN10reanimated16AndroidSchedulerEFvvEXadL_ZNS4_9triggerUIEvEES4_vJEE8dispatchENS0_9alias_refIPNS1_8JTypeForINS0_11HybridClassIS4_NS1_15BaseHybridClassEE8JavaPartENS0_7JObjectEvE11_javaobjectEEE+28)
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #12 pc 000000000002f314 /data/app/com.swmansion.reanimated.example-2/lib/arm64/libreanimated.so (_ZN8facebook3jni6detail15FunctionWrapperIPFvNS0_9alias_refIPNS1_8JTypeForINS0_11HybridClassIN10reanimated16AndroidSchedulerENS1_15BaseHybridClassEE8JavaPartENS0_7JObjectEvE11_javaobjectEEEEXadL_ZNS1_13MethodWrapperIMS7_FvvEXadL_ZNS7_9triggerUIEvEES7_vJEE8dispatchESF_EESE_vJEE4callEP7_JNIEnvP8_jobject+56)
2020-11-25 15:16:29.359 32407-32407/? A/DEBUG: #13 pc 0000000000659d80 /data/app/com.swmansion.reanimated.example-2/oat/arm64/base.odex (offset 0x5b7000)
Hermes version: 0.5.1 React Native version (if any): 0.63.0 Android version (if any): 11 on simulator/ 7 on device Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64): x86 simulator/arm64-v8a device
Thank you in advance ✌️
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 23 (12 by maintainers)
@tmikov @savv I’m not an expert when it comes to shared libraries and linking but Isn’t it a problem that libreactnative.so and libhermes.so contains the same symbols from jsi? I also tried the same approach as @savy by using jsi headers and linking jsi from jsc/hermes. However, I’m not sure what happens when libreactnative and libhermes have jsi symbols.
I managed to make exceptions work correctly on my C++ library, by linking JSI from RN’s distribution, instead of directly:
https://github.com/greentriangle/react-native-leveldb/commit/a2658307c2813ef8901e695a30c9c3697dd64d0e
credit to @mrousavy for figuring out first!
@kraenhansen, I was able to repro that crash, and it looks like a separate issue, having to do with a duplicate copy of libc++ in your build. The below change fixes it:
Closing, since the issue has been resolved.