-
Notifications
You must be signed in to change notification settings - Fork 69
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
Unsatisfied link error from libjscexecutor.so #29
Comments
@maman I am sorry that in order to reduce patches from RN, I reused the JSCExecutor code. However, the real problem should be the missing symbol Could you please check the v8-android version in your yarn.lock? |
I see somehow related error on some android 4.1 devices with react-native 0.60.5, v8-android 7.5.1:
The error is telling that libhermes.so is not found, but hermes is disabled in this build (as v8 is used), and it is happening because of error on trying to load jscexecutor (code in react native uses Hermes executor as fallback). Because of that I cannot see original error, but probably it can be related to the one described in this issue. |
@Kudo Removing that fallback to Hermes revealed that it is the same issue:
This is from HTC One (M8), API Level 19 from Firebase Test Lab, and it can be reproduced on other physical devices with API level 19 there. Also we have one confirmed case with real user with HTC One S API 16 reporting that crash (obscured by Hermes fallback, but I think it is the same one). I've tried the instructions to check the symbol, not sure that I've done it correctly, but here it is (please correct me if I misunderstood something):
Result is:
|
@Kudo sorry for the slow reply - here's my app details:
Curiously, the libv8 libraries on 64-bit archs apk aren't recognized 🤔 |
hmm.. found some clue from RN's issue here: facebook/react-native#23764 (comment)
haven't tried that, because I didn't exactly know why that "fixed" the problem 😅 |
@maman that is default configuration that was added in RN 0.60.1 (see https://react-native-community.github.io/upgrade-helper/?from=0.60.0&to=0.60.1), and was removed then in 0.61 (facebook/react-native@509a07b). Since I have RN 0.60.5, I have that pickFirst options in my app/build.gradle, but that does not help. |
@biomancer ah yep, ok 👍 also I forgot to mention - I'm still on 0.59.10 (also adding the info on my initial issue post) |
@maman @biomancer
You addresses are both And my address is Even though you should use correct ABI toolchain, but it seems the address is different to me for arm ABI. For the question, could you please provide md5 checksum for the libv8.so? $ md5 lib/*/libv8.so
MD5 (lib/arm64-v8a/libv8.so) = ecfa63056e04652f77f737834d70f818
MD5 (lib/armeabi-v7a/libv8.so) = 1ccff44a1445cce5071e872cef958240
MD5 (lib/x86/libv8.so) = e66fd6242d630231d34ea765d231d519
MD5 (lib/x86_64/libv8.so) = f625beae7fa0a24a88eb22f6781d58de
|
@Kudo I think I understood why files differ - I forgot that we use v8-android-nointl (also 7.5.1), and v8-android is actually an unused dependency. I've unzipped libs from npm to check it: Full version: I'll try to setup test app both with full and nointl versions and check in Firebase Test Lab |
ah yes @Kudo - we also use here's the md5:
regarding the firebase testlab, I'll try to do it over this week - will report the result |
I've set up test app https://github.com/biomancer/react-native-v8-debug-app/commits/master and tried different combinations, here is what I've found:
Here is the crash for Android 9 arm 64:
and here it is from API 19 emulator:
I guess it is another issue, but probably it is related and it's definitely more reproducible, maybe it will help to get the idea about original issue? Also I've noticed some issues with versioning of v8-android, I had to add manual resolutions block in package.json to be sure what version is used. My NDK version is 17.2.4988734 p.s. About that Hermes fallback - maybe it's possible to use fallback only when .so is missing and rethrow (or how that's called in Java) in other cases likethis one? Even more in react-native-v8 maybe there is no reason to fallback at all if we are sure that v8 is used? Clear linker errors would make things a bit easier to debug/google/etc. |
@Kudo reproduced via firebase device test lab, on HTC M8, API 19: Here's the stack trace for:
I also check the updated react-native-v8, also crashed on the same device:
|
@biomancer @maman Thanks for your amazing information. |
you're welcome! - let me know if you need any help 🙂 |
make sure: "react-native-v8": "0.59.10-patch.2", => "[email protected]", crash bacause: react-native-v8 |
@wv1124 yep - there's breaking changes on v8-7.8.0 that requires updated react-native-v8 package. My stacktrace above already have the correct pair of packages. |
Summary: On some Android device, there is libv8.so in system ROM. E.g. /system/lib/libv8.so or /vendor/lib/libv8.so On old Android, dlopen() with RTLD_GLOBAL is not handled well and it's by default RTLD_LOCAL. Even we call System.loadLibrary("v8") before, during the time RNV8 call System.loadLibrary("v8executor") and search libv8.so in DT_NEEDED. It seems bionic linker will use system libv8.so instead of ours. Since our libv8.so is customized with libplatform.so, this leads to unresolved symbol as Kudo/react-native-v8#29. That's why I am proposing to rename libv8.so as libv8android.so and to prevent name conflict from system libv8.so. Reference for RTLD_GLOBAL: android/ndk#201
Summary: On some Android device, there is libv8.so in system ROM. E.g. /system/lib/libv8.so or /vendor/lib/libv8.so On old Android, dlopen() with RTLD_GLOBAL is not handled well and it's by default RTLD_LOCAL. Even we call System.loadLibrary("v8") before, during the time RNV8 call System.loadLibrary("v8executor") and search libv8.so in DT_NEEDED. It seems bionic linker will use system libv8.so instead of ours. Since our libv8.so is customized with libplatform.so, this leads to unresolved symbol as #29. That's why I am proposing to rename libv8.so as libv8android.so and to prevent name conflict from system libv8.so. Reference for RTLD_GLOBAL: android/ndk#201
Summary: On some Android device, there is libv8.so in system ROM. E.g. /system/lib/libv8.so or /vendor/lib/libv8.so On old Android, dlopen() with RTLD_GLOBAL is not handled well and it's by default RTLD_LOCAL. Even we call System.loadLibrary("v8") before, during the time RNV8 call System.loadLibrary("v8executor") and search libv8.so in DT_NEEDED. It seems bionic linker will use system libv8.so instead of ours. Since our libv8.so is customized with libplatform.so, this leads to unresolved symbol as #29. That's why I am proposing to rename libv8.so as libv8android.so and to prevent name conflict from system libv8.so. Reference for RTLD_GLOBAL: android/ndk#201
Summary: On some Android device, there is libv8.so in system ROM. E.g. /system/lib/libv8.so or /vendor/lib/libv8.so On old Android, dlopen() with RTLD_GLOBAL is not handled well and it's by default RTLD_LOCAL. Even we call System.loadLibrary("v8") before, during the time RNV8 call System.loadLibrary("v8executor") and search libv8.so in DT_NEEDED. It seems bionic linker will use system libv8.so instead of ours. Since our libv8.so is customized with libplatform.so, this leads to unresolved symbol as #29. That's why I am proposing to rename libv8.so as libv8android.so and to prevent name conflict from system libv8.so. Reference for RTLD_GLOBAL: android/ndk#201 (cherry picked from commit 5a78dd5)
Summary: On some Android device, there is libv8.so in system ROM. E.g. /system/lib/libv8.so or /vendor/lib/libv8.so On old Android, dlopen() with RTLD_GLOBAL is not handled well and it's by default RTLD_LOCAL. Even we call System.loadLibrary("v8") before, during the time RNV8 call System.loadLibrary("v8executor") and search libv8.so in DT_NEEDED. It seems bionic linker will use system libv8.so instead of ours. Since our libv8.so is customized with libplatform.so, this leads to unresolved symbol as #29. That's why I am proposing to rename libv8.so as libv8android.so and to prevent name conflict from system libv8.so. Reference for RTLD_GLOBAL: android/ndk#201 (cherry picked from commit 5a78dd5)
@maman @biomancer This issue should be fixed by renaming libv8.so to libv8android.so. And sorry for yet another new breaking change.
Hopefully this will help your problems. @wv1124 Thanks for your information. |
thanks @Kudo! will test the changes btw, why this line is removed? 5a78dd5#diff-69b017bdf029e15f078c069fe9955acbL17 if I'm not mistaken, this means we didn't use edit: can confirm that the updated apk work fine when testing with HTC M8, API 19 via firebase device test lab. 👍 |
@maman Thanks for your help.
Before Android JB-MR2, the bionic linker cannot load dependencies correctly, Original I referenced this code from HermesExecutor, Hermes needs this for So we rely bionic linker to parse DT_NEEDED from libv8executor.so and it will find and load libv8android.so accordingly. |
Hi, I'm seeing this crash errors on my app - mostly it's happen on samsung, xiaomi, and oppo devices
From what I understand, react-native-v8 didn't use jsc anymore as it's using v8 instead - but the stacktrace reports some jsc-related libraries being loaded 🤔
I'm using:
0.59.10
0.59.10-patch.2
7.5.1
Stack trace:
we're using split builds & jumbo mode:
also probably related - we're seeing this error also on jsc builds, albeit with slightly different stacktrace - the culprit is the same, though - SoLoader can't find/link the libraries..
The text was updated successfully, but these errors were encountered: