Skip to content
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

Closed
maman opened this issue Nov 1, 2019 · 20 comments
Closed

Unsatisfied link error from libjscexecutor.so #29

maman opened this issue Nov 1, 2019 · 20 comments

Comments

@maman
Copy link

maman commented Nov 1, 2019

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:

  • react-native 0.59.10
  • react-native-v8 0.59.10-patch.2
  • and v8-android-nointl 7.5.1

Stack trace:

Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so caused by: Cannot load library: reloc_library[1306]:   233 cannot locate '_ZN2v88platform18NewDefaultPlatformEiNS0_15IdleTaskSupportENS0_21InProcessStackDumpingENSt6__ndk110unique_ptrINS_17TracingControllerENS3_14default_deleteIS5_EEEE'...

       at com.facebook.soloader.SoLoader.doLoadLibraryBySoName + 738(SoLoader.java:738)
       at com.facebook.soloader.SoLoader.loadLibraryBySoName + 591(SoLoader.java:591)
       at com.facebook.soloader.SoLoader.loadLibrary + 529(SoLoader.java:529)
       at com.facebook.soloader.SoLoader.loadLibrary + 484(SoLoader.java:484)
       at com.facebook.react.jscexecutor.JSCExecutor.<clinit> + 19(JSCExecutor.java:19)
       at com.facebook.react.jscexecutor.JSCExecutorFactory.create + 29(JSCExecutorFactory.java:29)
       at com.facebook.react.ReactInstanceManager$5.run + 944(ReactInstanceManager.java:944)
       at java.lang.Thread.run + 856(Thread.java:856)

we're using split builds & jumbo mode:

   splits {
        abi {
            reset()
            enable enableSeparateBuildPerCPUArchitecture
            universalApk false
            include "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
        }
    }
    dexOptions {
        jumboMode true
    }

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..

@Kudo
Copy link
Owner

Kudo commented Nov 1, 2019

@maman I am sorry that in order to reduce patches from RN, I reused the JSCExecutor code.
That's why the name is still having the JSC.
I will take some time to work on new version for dedicated V8Executor.

However, the real problem should be the missing symbol _ZN2v88platform18NewDefaultPlatformEiNS0_15IdleTaskSupportENS0_21InProcessStackDumpingENSt6__ndk110unique_ptrINS_17TracingControllerENS3_14default_deleteIS5_EEEE

Could you please check the v8-android version in your yarn.lock?
Moreover, you could further check the symbol from nm?
E.g.
/path/to/android-ndk-r17c/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm -CD jni/armeabi-v7a/libv8.so|grep NewDefaultPlatform
And the output
008945b6 T v8::platform::NewDefaultPlatform(int, v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, std::__ndk1::unique_ptr<v8::TracingController, std::__ndk1::default_delete<v8::TracingController> >)

@biomancer
Copy link

biomancer commented Nov 3, 2019

I see somehow related error on some android 4.1 devices with react-native 0.60.5, v8-android 7.5.1:

java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so
     FATAL EXCEPTION: create_react_context
Process: com.azradio, PID: 28170
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so
	at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
	at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
	at com.facebook.hermes.reactexecutor.HermesExecutor.<clinit>(HermesExecutor.java:20)
	at com.facebook.hermes.reactexecutor.HermesExecutorFactory.create(HermesExecutorFactory.java:27)
	at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:949)
	at java.lang.Thread.run(Thread.java:864)

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.
I'll try to build rn fork without this fallback code to see the original error and report back

@biomancer
Copy link

@Kudo Removing that fallback to Hermes revealed that it is the same issue:

java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: cannot locate symbol "_ZN2v88platform18NewDefaultPlatformEiNS0_15IdleTaskSupportENS0_21InProcessStackDumpingENSt6__ndk110unique_ptrINS_17TracingControllerENS3_14default_deleteIS5_EEEE" referenced by "libjscexecutor.so"...
     FATAL EXCEPTION: main
Process: com.azradio, PID: 8636
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: cannot locate symbol "_ZN2v88platform18NewDefaultPlatformEiNS0_15IdleTaskSupportENS0_21InProcessStackDumpingENSt6__ndk110unique_ptrINS_17TracingControllerENS3_14default_deleteIS5_EEEE" referenced by "libjscexecutor.so"...
	at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
	at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
	at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:304)
	at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:279)
	at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:88)
	at com.reactnativenavigation.react.NavigationReactGateway$ReactNativeHostImpl.createReactInstanceManager(NavigationReactGateway.java:158)
	at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:41)
	at com.reactnativenavigation.react.NavigationReactGateway.getReactInstanceManager(NavigationReactGateway.java:60)
	at com.reactnativenavigation.react.NavigationReactGateway.hasStartedCreatingContext(NavigationReactGateway.java:47)
	at com.reactnativenavigation.controllers.SplashActivity.onResume(SplashActivity.java:43)
	at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1282)
	at android.app.Activity.performResume(Activity.java:5405)
	at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3156)
	at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3211)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2500)
	at android.app.ActivityThread.access$800(ActivityThread.java:153)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1349)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loop(Looper.java:157)
	at android.app.ActivityThread.main(ActivityThread.java:5633)
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:515)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:896)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:712)
	at dalvik.system.NativeStart.main(Native Method)

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).
Only physical devices are affected, emulators are working fine.

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):

  1. v8-android version is 7.5.1
  2. I'm not sure what's jni folder from your instructions, so I've unpacked my apk with apktool to get used libs
  3. toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-nm -CD /path/to/unpackedApk/lib/armeabi-v7a/libv8.so | grep NewDefaultPlatform

Result is:

0020c896 T v8::platform::NewDefaultPlatform(int, v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, std::__ndk1::unique_ptr<v8::TracingController, std::__ndk1::default_delete<v8::TracingController> >)

@maman
Copy link
Author

maman commented Nov 5, 2019

@Kudo sorry for the slow reply - here's my app details:

  1. The lockfiles specify v8-android v7.5.1
  2. dump for all outputs from my split-builds apk:
ARMV7

~ λ Library/Android/sdk/ndk/20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm -CD /Users/maman/Downloads/2019-11-05/app-armeabi-v7a-prod-0.6.0-1.apk/lib/armeabi-v7a/libv8.so | grep NewDefaultPlatform
0020c896 T v8::platform::NewDefaultPlatform(int, v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, std::__ndk1::unique_ptr<v8::TracingController, std::__ndk1::default_delete<v8::TracingController> >)

ARM64-V8A
~ λ Library/Android/sdk/ndk/20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm -CD /Users/maman/Downloads/2019-11-05/app-arm64-v8a-prod-0.6.0-1.apk/lib/arm64-v8a/libv8.so | grep NewDefaultPlatform
Library/Android/sdk/ndk/20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm: /Users/maman/Downloads/2019-11-05/app-arm64-v8a-prod-0.6.0-1.apk/lib/arm64-v8a/libv8.so: File format not recognized

x86
~ λ Library/Android/sdk/ndk/20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm -CD /Users/maman/Downloads/2019-11-05/app-armeabi-v7a-prod-0.6.0-1.apk/lib/armeabi-v7a/libv8.so | grep NewDefaultPlatform
0020c896 T v8::platform::NewDefaultPlatform(int, v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, std::__ndk1::unique_ptr<v8::TracingController, std::__ndk1::default_delete<v8::TracingController> >)

x86-64
~ λ Library/Android/sdk/ndk/20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm -CD /Users/maman/Downloads/2019-11-05/app-x86_64-prod-0.6.0-1.apk/lib/x86_64/libv8.so | grep NewDefaultPlatform
Library/Android/sdk/ndk/20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm: /Users/maman/Downloads/2019-11-05/app-x86_64-prod-0.6.0-1.apk/lib/x86_64/libv8.so: File format not recognized

Curiously, the libv8 libraries on 64-bit archs apk aren't recognized 🤔

@maman
Copy link
Author

maman commented Nov 5, 2019

hmm.. found some clue from RN's issue here: facebook/react-native#23764 (comment)

packagingOptions {
        pickFirst '**/armeabi-v7a/libc++_shared.so'
        pickFirst '**/x86/libc++_shared.so'
        pickFirst '**/arm64-v8a/libc++_shared.so'
        pickFirst '**/x86_64/libc++_shared.so'
        pickFirst '**/x86/libjsc.so'
        pickFirst '**/armeabi-v7a/libjsc.so'
    }
}

haven't tried that, because I didn't exactly know why that "fixed" the problem 😅

@biomancer
Copy link

biomancer commented Nov 5, 2019

@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.
Kudo is definitely aware of these changes as he merged them:)

@maman
Copy link
Author

maman commented Nov 5, 2019

@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)

@Kudo
Copy link
Owner

Kudo commented Nov 5, 2019

@maman @biomancer
Thanks for your information.
I need some more information, hopefully if you could answer these questions.

  1. Could you in-house reproduce this problem? It would be great if we could reproduce the issue. It seems @biomancer could reproduce from Firebase Test Lab. Is it possible to reproduce the issue on Android API 19 x86 official emulator ?

  2. Does the crash happens on pure app, i.e. npx react-native init TestApp --version 0.60.5 + react-native-v8 support? Or this crash happens only on your app?

  3. The most weird thing to me is your v8::platform::NewDefaultPlatform symbol address.

You addresses are both
0020c896 T v8::platform::NewDefaultPlatform(int, v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, std::__ndk1::unique_ptr<v8::TracingController, std::__ndk1::default_deletev8::TracingController >)

And my address is
008945b6 T v8::platform::NewDefaultPlatform(int, v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, std::__ndk1::unique_ptr<v8::TracingController, std::__ndk1::default_deletev8::TracingController >)

Even though you should use correct ABI toolchain, but it seems the address is different to me for arm ABI.
(@maman That's why your x86_64 file format was not recognized: Library/Android/sdk/ndk/20.0.5594570/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm -CD /Users/maman/Downloads/2019-11-05/app-x86_64-prod-0.6.0-1.apk/lib/x86_64/libv8.so | grep NewDefaultPlatform)

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
  1. Your host OS (MacOS / Linux / Windows) and NDK version if you have.

@biomancer
Copy link

biomancer commented Nov 5, 2019

@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:
Nointl:
$ANDROID_NDK/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-nm -CD ./node_modules/v8-android-nointl/dist/lib.unstripped/v8-android/7.5.1/libs/armeabi-v7a/libv8.so | grep NewDefaultPlatform
0020c896 T v8::platform::NewDefaultPlatform(int, v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, std::__ndk1::unique_ptr<v8::TracingController, std::__ndk1::default_delete<v8::TracingController> >)

Full version:
$ANDROID_NDK/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-nm -CD ./node_modules/v8-android/dist/lib.unstripped/v8-android/7.5.1/libs/armeabi-v7a/libv8.so | grep NewDefaultPlatform
008945b6 T v8::platform::NewDefaultPlatform(int, v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, std::__ndk1::unique_ptr<v8::TracingController, std::__ndk1::default_delete<v8::TracingController> >)

I'll try to setup test app both with full and nointl versions and check in Firebase Test Lab

@maman
Copy link
Author

maman commented Nov 5, 2019

ah yes @Kudo - we also use v8-android-nointl, version 7.5.1 🙇‍♂️

here's the md5:

MD5 (app-arm64-v8a-prod-0.6.0-1.apk/lib/arm64-v8a/libv8.so) = 7aedb110c79cdb52fc233f968d8341c3
MD5 (app-armeabi-v7a-prod-0.6.0-1.apk/lib/armeabi-v7a/libv8.so) = b57b9bf62fd5f61e30fd8557a2afa598
MD5 (app-x86-prod-0.6.0-1.apk/lib/x86/libv8.so) = 5db2d24ec10ca6dfa75a52acd166bc23
MD5 (app-x86_64-prod-0.6.0-1.apk/lib/x86_64/libv8.so) = 3d1f95c6d7d60244c05ef285947b0c16

regarding the firebase testlab, I'll try to do it over this week - will report the result

@biomancer
Copy link

biomancer commented Nov 5, 2019

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:

  1. this particular crash is only reproduced in test lab on physical device with API 19, the same apk on API 19 emulator works fine both locally and in test lab.
  2. This crash is happening in test lab both for full version and nointl version, for @7.5.1
  3. Version with [email protected] or [email protected] (which is installed now by default if you follow react-native-v8 readme instructions) has another missing symbol crash, and that crash is more generic and is reproduced on emulator and also on android 9 physical device, and also in dev mode, anywhere I've tried. I thought initially that it is the same crash, but using RN fork with disabled fallback to Hermes shows that it's about another symbol (I'm not sure that it's reliable though, as that modified react-native-v8 that I used to patch the fork uses [email protected], but the app anyway crashes with some UnsatisfiedLinkError even with original RN and react-native-v8):

Here is the crash for Android 9 arm 64:

11-05 21:38:47.023 21719 21719 E AndroidRuntime: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: cannot locate symbol "_ZN2v819ResourceConstraintsC1Ev" referenced by "/data/app/com.testapp-4Xibd6VKO_XCK9f3oLwjgw==/lib/arm64/libjscexecutor.so"...
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:304)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:279)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:88)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:41)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.react.ReactActivityDelegate.loadApp(ReactActivityDelegate.java:91)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.react.ReactActivityDelegate.onCreate(ReactActivityDelegate.java:80)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.facebook.react.ReactActivity.onCreate(ReactActivity.java:52)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.app.Activity.performCreate(Activity.java:7458)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.app.Activity.performCreate(Activity.java:7448)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1286)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3409)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3614)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:86)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2199)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:112)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:216)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:7625)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:524)
11-05 21:38:47.023 21719 21719 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:987)

and here it is from API 19 emulator:

E/AndroidRuntime( 6380): FATAL EXCEPTION: main
E/AndroidRuntime( 6380): Process: com.testapp, PID: 6380
E/AndroidRuntime( 6380): java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: cannot locate symbol "_ZN2v819ResourceConstraintsC1Ev" referenced by "libjscexecutor.so"...
E/AndroidRuntime( 6380):        at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
E/AndroidRuntime( 6380):        at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
E/AndroidRuntime( 6380):        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
E/AndroidRuntime( 6380):        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
E/AndroidRuntime( 6380):        at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:304)
E/AndroidRuntime( 6380):        at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:279)
E/AndroidRuntime( 6380):        at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:88)
E/AndroidRuntime( 6380):        at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:41)
E/AndroidRuntime( 6380):        at com.facebook.react.ReactActivityDelegate.loadApp(ReactActivityDelegate.java:91)
E/AndroidRuntime( 6380):        at com.facebook.react.ReactActivityDelegate.onCreate(ReactActivityDelegate.java:80)
E/AndroidRuntime( 6380):        at com.facebook.react.ReactActivity.onCreate(ReactActivity.java:52)
E/AndroidRuntime( 6380):        at android.app.Activity.performCreate(Activity.java:5231)
E/AndroidRuntime( 6380):        at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1087)
E/AndroidRuntime( 6380):        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2159)
E/AndroidRuntime( 6380):        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2245)
E/AndroidRuntime( 6380):        at android.app.ActivityThread.access$800(ActivityThread.java:135)
E/AndroidRuntime( 6380):        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1196)
E/AndroidRuntime( 6380):        at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime( 6380):        at android.os.Looper.loop(Looper.java:136)
E/AndroidRuntime( 6380):        at android.app.ActivityThread.main(ActivityThread.java:5017)
E/AndroidRuntime( 6380):        at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 6380):        at java.lang.reflect.Method.invoke(Method.java:515)
E/AndroidRuntime( 6380):        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
E/AndroidRuntime( 6380):        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
E/AndroidRuntime( 6380):        at dalvik.system.NativeStart.main(Native Method)

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
My os is macOS 10.13.6.

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.

@maman
Copy link
Author

maman commented Nov 6, 2019

@Kudo reproduced via firebase device test lab, on HTC M8, API 19:

Here's the stack trace for:

  • react-native-v8 v0.59.10-patch.2
  • android-v8-nointl 7.5.1
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: cannot locate symbol "_ZN2v88platform18NewDefaultPlatformEiNS0_15IdleTaskSupportENS0_21InProcessStackDumpingENSt6__ndk110unique_ptrINS_17TracingControllerENS3_14default_deleteIS5_EEEE" referenced by "libjscexecutor.so"...
     FATAL EXCEPTION: create_react_context
Process: <redacted>, PID: 17392
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: cannot locate symbol "_ZN2v88platform18NewDefaultPlatformEiNS0_15IdleTaskSupportENS0_21InProcessStackDumpingENSt6__ndk110unique_ptrINS_17TracingControllerENS3_14default_deleteIS5_EEEE" referenced by "libjscexecutor.so"...
	at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
	at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
	at com.facebook.react.jscexecutor.JSCExecutor.<clinit>(JSCExecutor.java:19)
	at com.facebook.react.jscexecutor.JSCExecutorFactory.create(JSCExecutorFactory.java:29)
	at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:944)
	at java.lang.Thread.run(Thread.java:864)

I also check the updated react-native-v8, also crashed on the same device:

  • react-native-v8 v0.59.10-patch.3
  • android-v8-nointl 7.8.0
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libv8executor.so caused by: dlopen failed: cannot locate symbol "_ZN2v88platform18NewDefaultPlatformEiNS0_15IdleTaskSupportENS0_21InProcessStackDumpingENSt6__ndk110unique_ptrINS_17TracingControllerENS3_14default_deleteIS5_EEEE" referenced by "libv8executor.so"...
     FATAL EXCEPTION: create_react_context
Process: <redacted>, PID: 28544
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libv8executor.so caused by: dlopen failed: cannot locate symbol "_ZN2v88platform18NewDefaultPlatformEiNS0_15IdleTaskSupportENS0_21InProcessStackDumpingENSt6__ndk110unique_ptrINS_17TracingControllerENS3_14default_deleteIS5_EEEE" referenced by "libv8executor.so"...
	at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
	at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
	at com.facebook.v8.reactexecutor.V8Executor.<clinit>(V8Executor.java:18)
	at com.facebook.v8.reactexecutor.V8ExecutorFactory.create(V8ExecutorFactory.java:17)
	at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:944)
	at java.lang.Thread.run(Thread.java:864)

@Kudo
Copy link
Owner

Kudo commented Nov 6, 2019

@biomancer @maman Thanks for your amazing information.
I was able to reproduce the issue on Firebase Test Lab M8 as well and had some thought for the issue.
Will try some solution but it takes some time for me. Please stay tune and will let you know for any updates.

@maman
Copy link
Author

maman commented Nov 6, 2019

you're welcome! - let me know if you need any help 🙂

@wv1124
Copy link

wv1124 commented Nov 6, 2019

make sure:
"react-native-v8": "0.59.10-patch.3", => "[email protected]", ok
"react-native-v8": "0.59.10-patch.2", => "[email protected]", ok

"react-native-v8": "0.59.10-patch.2", => "[email protected]", crash

bacause: react-native-v8
"dependencies": {
"v8-android": "^7.8.0"
},

@maman
Copy link
Author

maman commented Nov 7, 2019

@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.

Kudo added a commit to Kudo/v8-android-buildscripts that referenced this issue Nov 7, 2019
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
Kudo added a commit that referenced this issue Nov 7, 2019
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
Kudo added a commit that referenced this issue Nov 7, 2019
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
Kudo added a commit that referenced this issue Nov 7, 2019
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)
Kudo added a commit that referenced this issue Nov 7, 2019
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)
@Kudo
Copy link
Owner

Kudo commented Nov 7, 2019

@maman @biomancer This issue should be fixed by renaming libv8.so to libv8android.so.
More information is described at 5a78dd5

And sorry for yet another new breaking change.
Please use v8-android 7.8.1 with any of these versions:

  • v0.59.10-patch.4
  • v0.60.6-patch.2
  • v0.61.1-patch.3
  • v0.61.2-patch.1
  • v0.61.3-patch.1
  • v0.61.4-patch.1

Hopefully this will help your problems.

@wv1124 Thanks for your information.
As mentioned here, please upgrade to use
"0.59.10-patch.4", => "[email protected]", if you upgrade v8-android.

@maman
Copy link
Author

maman commented Nov 7, 2019

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 SoLoader to load the modules, and rely to android to load correct libraries on runtime?

edit:

can confirm that the updated apk work fine when testing with HTC M8, API 19 via firebase device test lab. 👍

@Kudo
Copy link
Owner

Kudo commented Nov 8, 2019

@maman Thanks for your help.

btw, why this line is removed? 5a78dd5#diff-69b017bdf029e15f078c069fe9955acbL17
if I'm not mistaken, this means we didn't use SoLoader to load the modules, and rely to android to load correct libraries on runtime?

Before Android JB-MR2, the bionic linker cannot load dependencies correctly,
but SoLoader will handle for this case.

Original I referenced this code from HermesExecutor, Hermes needs this for JNI_OnLoad execution.
libv8android.so does not have JNI_OnLoad and it is not necessary to load lib8android.so here.

So we rely bionic linker to parse DT_NEEDED from libv8executor.so and it will find and load libv8android.so accordingly.
The root cause for the issue is that we cannot control bionic linker search order (Seems we cannot add LD_LIBRARY_PATH) and it use system libv8.so instead of ours.

@maman
Copy link
Author

maman commented Nov 8, 2019

ah, i see 👍 thanks for the explanation @Kudo!

closing this issue now, because you fixes this on 5a78dd5 🙇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants