Hermes: RN 0.63.0 + enableHermes -> crash on start
Bug Description
Got this failure after switching to RN 0.63.0 and enabling Hermes (following https://reactnative.dev/docs/hermes):
Hermes version: ?
React Native version: 0.63.0
Android version: Android 10
Device: Samsung galaxy s20
From logcat:
2020-07-16 11:23:30.983 6540-6704/com.evernote E/unknown:ReactNative: ReactInstanceManager.createReactContext: mJSIModulePackage not null
2020-07-16 11:23:30.984 6540-6704/com.evernote E/unknown:ReactNative: ReactInstanceManager.createReactContext: ReactFeatureFlags.useTurboModules == false
2020-07-16 11:23:30.991 6540-6719/com.evernote E/unknown:ReactNative: ReactInstanceManager.attachRootViewToInstance()
2020-07-16 11:23:31.040 6540-6719/com.evernote E/Evernote聽cache: loaded webconfiguration
2020-07-16 11:23:31.044 6540-6719/com.evernote E/Evernote聽cache: loaded webconfiguration
2020-07-16 11:23:31.124 6540-6719/com.evernote E/unknown:ReactRootView: runApplication: call AppRegistry.runApplication
2020-07-16 11:23:31.131 1199-2381/? E/WifiService: 10348 has no permission about LOCAL_MAC_ADDRESS
2020-07-16 11:23:31.480 6540-6718/com.evernote E/unknown:ReactNative: CatalystInstanceImpl caught native exception
com.facebook.jni.UnknownCppException: Unknown
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:237)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
at java.lang.Thread.run(Thread.java:919)
2020-07-16 11:23:31.481 6540-6718/com.evernote E/unknown:ReactNative: Exception in native call
com.facebook.jni.UnknownCppException: Unknown
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:237)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
at java.lang.Thread.run(Thread.java:919)
2020-07-16 11:23:31.486 6540-6718/com.evernote E/ReactNativeJNI: Attempting to call JS function on a bad application bundle: HMRClient.setup()
2020-07-16 11:23:31.488 6540-6718/com.evernote E/unknown:ReactNative: CatalystInstanceImpl caught native exception
java.lang.RuntimeException: Attempting to call JS function on a bad application bundle: HMRClient.setup()
........
2020-07-16 11:23:31.488 6540-6718/com.evernote E/unknown:ReactNative: Exception in native call
java.lang.RuntimeException: Attempting to call JS function on a bad application bundle: HMRClient.setup()
........
2020-07-16 11:23:31.489 6540-6718/com.evernote E/ReactNativeJNI: Attempting to call JS function on a bad application bundle: AppRegistry.runApplication()
2020-07-16 11:23:31.490 6540-6718/com.evernote E/unknown:ReactNative: CatalystInstanceImpl caught native exception
java.lang.RuntimeException: Attempting to call JS function on a bad application bundle: AppRegistry.runApplication()
........
2020-07-16 11:23:31.490 6540-6718/com.evernote E/unknown:ReactNative: Exception in native call
java.lang.RuntimeException: Attempting to call JS function on a bad application bundle: AppRegistry.runApplication()
........
2020-07-16 11:23:31.490 6540-6718/com.evernote E/ReactNativeJNI: Attempting to call JS function on a bad application bundle: RCTDeviceEventEmitter.emit()
2020-07-16 11:23:31.492 6540-6718/com.evernote E/unknown:ReactNative: CatalystInstanceImpl caught native exception
java.lang.RuntimeException: Attempting to call JS function on a bad application bundle: RCTDeviceEventEmitter.emit()
........
2020-07-16 11:23:31.492 6540-6718/com.evernote E/unknown:ReactNative: Exception in native call
java.lang.RuntimeException: Attempting to call JS function on a bad application bundle: RCTDeviceEventEmitter.emit()
........
Please help. Thank you.
alexkrav
All 33 comments
I also noticed error line shown before above exceptions:
2020-07-16 14:24:03.927 6037-6037/? E/SoLoader: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: library "libjsc.so" not found result: 0
Could you check node_modules/hermes-engine/package.json for which version of Hermes you're using?
The SoLoader error should be benign: if the app does not explicitly specify a VM at Runtime, React Native will simply try to load JSC, Hermes Debug, and Hermes Release in turn until one succeeds.
willholen
on 17 Jul 2020
@willholen , thank you for you answer.
{
"name": "hermes-engine",
"version": "0.5.0",
"private": false,
"description": "A JavaScript engine optimized for running React Native on Android",
"license": "MIT",
"repository": {
"type": "git",
"url": "[email protected]:facebook/hermes.git"
},
"files": [
"README.md",
"android/hermes-debug.aar",
"android/hermes-release.aar",
"android/hermes-cppruntime-debug.aar",
"android/hermes-cppruntime-release.aar",
"android/include/**/*.h",
"linux64-bin/hermesc",
"osx-bin/hermesc",
"win64-bin/hermesc.exe",
"win64-bin/msvcp140.dll",
"win64-bin/vcruntime140.dll"
]
}
@alexkrav There appears to be a native exception thrown during the initial bundle execution, but unfortunately all the information about what went wrong was lost during the C++-to-Java Exception conversion, resulting in the rather unhelpful com.facebook.jni.UnknownCppException: Unknown. We're trying to figure out why the actual error message is being lost.
Meanwhile, can you see if you're able to attach a native debugger and get a stack trace of this (handled) C++ exception?
It will probably be unsymbolicated, but it would be very helpful just to see which libraries are involved. For example, whether the exception originally came from libhermes.so or libreactnativejni.so or something else, and which libraries it travelled through before it became a Java exception.
willholen
on 17 Jul 2020
thank you @willholen
upon debugging we found that this exception was inspired by Flipper initialising.
After commenting it out, we went further but we've got signal 6 (SIGABRT) crash:
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
.....
backtrace:
#00 pc 00000000000832a8 /apex/com.android.runtime/lib64/bionic/libc.so (abort+160) (BuildId: c2f522895fa97ff8c517cefefec04171)
#01 pc 00000000000a5568 /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libreactnativejni.so (_Unwind_SetGR+16) (BuildId: 7e166bc5cfb525e50764e8070aa3b
#02 pc 00000000000b8550 /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libfbjni.so (__gxx_personality_v0+244) (BuildId: 8edc347b17ae03442aeaf32376fe2c
#03 pc 0000000000269e64 /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libhermes.so (BuildId: a922e4d5d2687e5c35d9663e65f2b548cd5bf0bc)
#04 pc 000000000026a36c /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libhermes.so (_Unwind_Resume+116) (BuildId: a922e4d5d2687e5c35d9663e65f2b548cd5
#05 pc 000000000002b08c /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libhermes.so (facebook::hermes::HermesRuntimeImpl::evaluateJavaScript(std::__nd
#06 pc 0000000000026a5c /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libhermes-executor-debug.so (facebook::react::JSIExecutor::loadBundle(std::__nd
#07 pc 00000000000a0958 /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libreactnativejni.so (BuildId: 7e166bc5cfb525e50764e8070aa3ba1e3a0e4fdf)
#08 pc 00000000000a2350 /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libreactnativejni.so (BuildId: 7e166bc5cfb525e50764e8070aa3ba1e3a0e4fdf)
#09 pc 0000000000068d48 /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libreactnativejni.so (BuildId: 7e166bc5cfb525e50764e8070aa3ba1e3a0e4fdf)
#10 pc 0000000000059a70 /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libreactnativejni.so (_ZN8facebook3jni6detail13MethodWrapperIMNS_5react15JNativ
#11 pc 00000000000599ec /data/app/com.evernote-ZWhf9gh9Ne1eVQZ6cGc5UA==/lib/arm64/libreactnativejni.so (_ZN8facebook3jni6detail15FunctionWrapperIPFvNS0_9alias_re
#12 pc 0000000000140350 /apex/com.android.runtime/lib64/libart.so (art_quick_generic_jni_trampoline+144) (BuildId: 35702844f057aa61fc9cb8543cfd5979)
#13 pc 0000000000137334 /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: 35702844f057aa61fc9cb8543cfd5979)
#14 pc 0000000000145fec /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+2
#15 pc 00000000002e3c10 /apex/com.android.runtime/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::Shado
#16 pc 00000000002dee70 /apex/com.android.runtime/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&,
#17 pc 00000000005a3258 /apex/com.android.runtime/lib64/libart.so (MterpInvokeInterface+980) (BuildId: 35702844f057aa61fc9cb8543cfd5979)
Obviously Flipper shouldn't be crashing, but I'm glad it got further. Since it appears that you're now hitting an abort/assert instead a C++ exception, the logged error details are hopefully more useful than before.
Can you please include the whole logcat dump from this new crash (plus a pageful before it starts)?
Do you get the same result in release builds as in this development build?
willholen
on 18 Jul 2020
@willholen, thanks for release build suggestion. Release build started without exception and shows the first UI screen (log in screen) !
And even with Flipper initialized ! So, this SIGABRT crash seems debug build only issue ( maybe related to metro?).
Anyway full log is here:
debug_crash.txt
alexkrav
on 19 Jul 2020
@alexkrav Hi. I was experiencing similar error when upgrading from 0.62.2 to 0.63.1. In my case the issue was that I had undefined values in StyleSheet
const styles = StyleSheet.create({
x: undefined
});
The error was coming from react-native/Libraries/StyleSheetValidation.js validateStyle (line 50), which is parsing your StyleSheets in dev mode. The problem in my codebase was that I was using Platform.select(...) inside Stylesheet without specifying android config, which was returning undefined and causing validation error. Also disabling hermes gave me a better stacktrace to spot the issue.
jakmak24
on 20 Jul 2020
@jakmak24 Thank you. Unfortunately, this is not my case.
alexkrav
on 20 Jul 2020
@alexkrav My (incomplete) understanding of this crash is:
- A native exception is raised in libhermes evaluateJavaScript. Most frequently, this is due to a simple JavaScript compilation error, though it can also be a problem with native libraries that are being invoked from JavaScript (such as from third party libraries).
- For an unknown reason, maybe related to mismatched C++ libraries, the C++ exception unwinding framework is crashing instead of propagating the exception and showing the underlying message
In a release build, the bundle is built on the host before the app runs. The hope was that this would fail and reveal a JS compilation error due to some syntax that Hermes doesn't support, but since it succeeded there does not appear to be any such problems in the release version of the JavaScript bundle.
Could you:
- Clarify whether this worked on React Native 0.62 (which used Hermes 0.4.x), or whether you're trying out Hermes for the first time now? This would help narrow down when and where the problem arises. It could be Hermes, RN, or a 3rd party JS library with native components.
- Clarify whether this happens only on the Samsung Galaxy S20, or if it also happens on e.g. the x86_64 emulator? A different architecture with different stack unwinding may successfully propagate the exception and directly show a (hopefully) simple underlying issue
- See if the Hermes has any trouble understanding the development version of the bundle. With Metro running, you should be able to do this with
curl 'http://localhost:8081/index.bundle?platform=android&dev=true&minify=false' > bundle.jsto download the JavaScript from Metro. You can then usenode_modules/hermes-engine/osx-bin/hermesc bundle.js -emit-binary -out bundle.hbcto compile it (replacingosx-binwithlinux64-binorwin64-binas appropriate). Warnings are harmless, but an error will causebundle.hbcnot to be generated, and will pinpoint the problem. This will help determine if there's a JS issue that only manifests itself on Hermes in debug mode.
willholen
on 20 Jul 2020
@willholen
1) It worked with React Native 0.60 but crashed when we migrated to 0.62 (I've created issue for that #246 ). When I was told that Hermes 5.0 is for 0.63 - we started migration to 0.63 and here we are now.
2) The same failure happens on emulator as well.
3) This works and I could move further with Debug build (that was some lint like issues like { name: name, foo: foo } instead of {name, foo} led to SIGABRT crush on evaluateJavaScript() !??) - great method !!! I really appreciate your help!
and Now I have SIGABRT 11 :-)
alexkrav
on 21 Jul 2020
@alexkrav
Lint-like issues should not be causing a compilation failure, and therefore not the SIGABRT. I tried copy-pasting { name: name, foo: foo } into a file and ran hermes -O -emit-binary -out foo.hbc foo.js, and it successfully generated a bundle without warnings.
Did you originally see an error that prevented the creation of bundle.hbc? Or was bundle.hbc created successfully, but the code went further when fixed the linting issue?
willholen
on 21 Jul 2020
@willholen
I'm still struggling with "signal 11 SIGABRT" crashes.
Should I build Hermes from sources to see symbolic stacks? I've tried to follow instructions from Hermes github, but do not know how to integrate it with RN...
Thank you
alexkrav
on 23 Jul 2020
I have the same issue when migrating from react-native 62 to react-native 63.2.
We used Hermes without any issues on react-native 62.
I was able to to use the method above to download a bundle from metro and compile it via hermes binary,
I am also having signal 11 SIGABRT" crashes, when using Nexus 5 emulator.
Building the app without Hermes (enableHermes: false) works fine.
barakd
on 24 Jul 2020
Similarly getting this after enabling hermes on my app, it seems that these errors can be caused by bits of JS that the engine doesn't like. Commenting out large chunks of the app then running npm start -- --reset-cache fixes things until I find the next issue.
Edit: actually my issue was largely to do with storybook, the above mentioned really helped me, it seemed random at first however Im guessing that's down to some clever treeshaking.
curl 'http://localhost:8081/index.bundle?platform=android&dev=true&minify=false' > bundle.js
node_modules/hermes-engine/osx-bin/hermesc bundle.js -emit-binary -out bundle.hbc
kyle-ssg
on 26 Jul 2020
It looks like we also have the same issue, probably related to storybook.
yurykorzun
on 28 Jul 2020
hi there, experiencing the same issue here, we don't know the reason yet, disabling it for now.
eelmoni
on 4 Aug 2020
You can force to use v0.5.1 of hermes:
1- "hermes-engine": "0.5.1", - in your package.json in the dev dependencies
2- yarn install
3- yarn start --reset-cache
that's works for me , i'm currently using the version 0.63.2
kenMarquez
on 12 Aug 2020
I've tried multiple Hermes versions, from 0.1.1 right up to 0.6.0 including the one listed above and I still get the app crashing on startup :(
Eli-Nathan
on 15 Aug 2020
One thing to note @Eli-Nathan, you do need to do a gradlew clean when updating hermes engine to "hermes-engine": "0.5.1". yarn start --reset-cache is not enough.
Updating to 0.5.1 did fix things for me.
cd ./android
sh ./gradlew clean
That _seems_ to have fixed the Hermes issue!
Tried running ./gradlew clean on all the other versions but forgot for this one 馃う
Although...
In other versions, I was using:
project.ext.react = [
entryFile: "index.js",
enableHermes: true, // clean and rebuild if changing
hermesCommand: "../../node_modules/hermes-engine/osx-bin/hermes",
],
but with Hermes v0.5.1 the node_modules/hermes-engine/osx-bin/ directory only contains hermesc
Any idea if I should still link to that?
Eli-Nathan
on 15 Aug 2020
What version of RN are you running? I'm not sure setting hermesCommand is necessary. I definitely don't have that set, I haven't actually seen this perhaps it's deprecated?
kyle-ssg
on 15 Aug 2020
I'm on 0.63.2, yeah it gave me and error when i removed that line but another clean and build and we're all good. Android sure loves a good clean 馃檮 Thanks!
Eli-Nathan
on 15 Aug 2020
if you upgrade hermes, you need to change the hermesCommand to use hermesc instead hermes :
project.ext.react = [
....hermesOptions
enableHermes : true,
hermesCommand: "../../node_modules/hermes-engine/%OS-BIN%/hermesc",
]
Thanks guys for your investigation ! I just commented the import of the root of my storybook folder and now it's working !
martinezguillaume
on 31 Aug 2020
I'm still encountering the problem, even after installing [email protected] and following the cleaning steps.
When trying to build a release build, I'm getting several errors:
E/SoLoader: Error when loading lib: dlopen failed: library "libjsc.so" not found lib hash: b8f27e96efd57a06ab662393790c3ca4 search path is /data/app/com.myapp-iBZTq096c6CahqwodCcv3g==/lib/x86
W/System.err: java.lang.UnsatisfiedLinkError: dlopen failed: library "libjsc.so" not found
E/SoLoader: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: library "libjsc.so" not found result: 0
E/SoLoader: Error when loading lib: dlopen failed: cannot locate symbol "_ZN8facebook6hermes13HermesRuntime11getDebuggerEv" referenced by "/data/app/com.myapp-iBZTq096c6CahqwodCcv3g==/lib/x86/libhermes-executor-debug.so"... lib hash: a477b913f370c7fa52d37cf0d26cb01f search path is /data/app/com.myapp-iBZTq096c6CahqwodCcv3g==/lib/x86
E/SoLoader: couldn't find DSO to load: libhermes-executor-debug.so caused by: dlopen failed: cannot locate symbol "_ZN8facebook6hermes13HermesRuntime11getDebuggerEv" referenced by "/data/app/com.myapp-iBZTq096c6CahqwodCcv3g==/lib/x86/libhermes-executor-debug.so"... result: 0
E/unknown:ReactNative: ReactInstanceManager.createReactContext: mJSIModulePackage null
E/ReactNativeJNI: logMarker CREATE_REACT_CONTEXT_END
E/unknown:DisabledDevSupportManager: Caught exception
java.lang.RuntimeException: Unable to load script. Make sure you're either running a Metro server (run 'react-native start') or that your bundle 'index.android.bundle' is packaged correctly for release.
This is the order they appear in the debug tab of Android Studio.
When disabling Hermes, only the last error still persists:
E/unknown:ReactNative: ReactInstanceManager.createReactContext: mJSIModulePackage null
E/ReactNativeJNI: logMarker CREATE_REACT_CONTEXT_END
fritzfr
on 4 Sep 2020
I'm still encountering the problem, even after installing
[email protected]and following the cleaning steps.When trying to build a release build, I'm getting several errors:
E/SoLoader: Error when loading lib: dlopen failed: library "libjsc.so" not found lib hash: b8f27e96efd57a06ab662393790c3ca4 search path is /data/app/com.myapp-iBZTq096c6CahqwodCcv3g==/lib/x86
W/System.err: java.lang.UnsatisfiedLinkError: dlopen failed: library "libjsc.so" not foundE/SoLoader: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: library "libjsc.so" not found result: 0
E/SoLoader: Error when loading lib: dlopen failed: cannot locate symbol "_ZN8facebook6hermes13HermesRuntime11getDebuggerEv" referenced by "/data/app/com.myapp-iBZTq096c6CahqwodCcv3g==/lib/x86/libhermes-executor-debug.so"... lib hash: a477b913f370c7fa52d37cf0d26cb01f search path is /data/app/com.myapp-iBZTq096c6CahqwodCcv3g==/lib/x86
E/SoLoader: couldn't find DSO to load: libhermes-executor-debug.so caused by: dlopen failed: cannot locate symbol "_ZN8facebook6hermes13HermesRuntime11getDebuggerEv" referenced by "/data/app/com.myapp-iBZTq096c6CahqwodCcv3g==/lib/x86/libhermes-executor-debug.so"... result: 0
E/unknown:ReactNative: ReactInstanceManager.createReactContext: mJSIModulePackage null
E/ReactNativeJNI: logMarker CREATE_REACT_CONTEXT_END
E/unknown:DisabledDevSupportManager: Caught exception
java.lang.RuntimeException: Unable to load script. Make sure you're either running a Metro server (run 'react-native start') or that your bundle 'index.android.bundle' is packaged correctly for release.This is the order they appear in the debug tab of Android Studio.
When disabling Hermes, only the last error still persists:
E/unknown:ReactNative: ReactInstanceManager.createReactContext: mJSIModulePackage null
E/ReactNativeJNI: logMarker CREATE_REACT_CONTEXT_END
E/unknown:ReactNative: Unable to launch logbox because react was unable to create the root view
E/ReactNativeJS: TypeError: null is not an object (evaluating 't(r(d[1])).default.Direction')
E/unknown:ReactNative: CatalystInstanceImpl caught native exception
songhanlin
on 8 Sep 2020
@alexkrav if you're getting a signal 11, you should be getting a native stack trace in logcat. If you can reproduce it with 0.5.1 or newer, there are instructions to symbolicate the native stack here: https://github.com/facebook/hermes/blob/master/doc/ReactNativeIntegration.md#reporting-native-crashes. Or you can post the crash from logcat, and we can try to help, but only for 0.5.1 and newer.
mhorowitz
on 10 Sep 2020
@fritzfr and @songhanlin your errors do not seem to be related to the one in this issue. Please use the "New Issue" button or go to https://github.com/facebook/hermes/issues/new/choose to file a new issue. Thanks!
mhorowitz
on 10 Sep 2020
@mhorowitz Thank you.
Here is crash log (original and symbolicated) I've got for
Hermes version: 0.5.2-rc1
React Native version: 0.63.2
Android version: 10
Platform: arm64-v8a
alexkrav
on 10 Sep 2020
Seems like this could be related. https://github.com/facebook/react-native/issues/25537
I think I'm encountering the same issue, very difficult to track down. I was using a custom fork of RN (almost identical to 0.63.2). I removed that to go back to vanilla 0.63.2. As soon as I did that the app started crashing on boot.
edit: doh! Android Studio inserted import com.facebook.react.BuildConfig; into my MainApplication.java which doesn't cause any build failures but it does prevent the app from connecting to metro in debug mode and crashes it. Just removing that line did the trick.
AndrewMorsillo
on 14 Sep 2020
@alexkrav I was looking at the stack trace you're showing, and this might be an issue we've been seeing for a while, but haven't found a fix for yet.
Specifically, the crash you mention is in hermes::vm::AlignedHeapSegment::segmentIndexFromStart, and it segfaults trying to read the heap segment index. Unfortunately, the stack trace alone for this case is insufficient to figure out the cause. We'll need a way to reproduce this to get a full core dump, or with a debugger attached.
I'll separate that crash into a different task, because this task has become over-aggregated. There are various crashes detailed here, and we can't follow all the threads.
dulinriley
on 8 Oct 2020
For any future occurrences or information on the AlignedHeapSegment::segmentIndexFromStart crash, please direct comments to #383.
dulinriley
on 8 Oct 2020
Related issues
gaodeng
路
4Comments
Gregoirevda
路
3Comments
benjamingr
路
6Comments
swabbass
路
3Comments
NWU-NISL
路
4Comments
Most helpful comment
if you upgrade hermes, you need to change the
hermesCommandto usehermescinsteadhermes: