-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
bug: crashing on Android debug build with RN 0.75 #6415
Comments
Same problem here in RN 0.75.1. node_modules/react-native-reanimated/android/src/main/java/com/swmansion/reanimated/ReactNativeUtils.java:17: error: cannot find symbol node_modules/react-native-reanimated/android/src/reactNativeVersionPatch/ReanimatedUIManager/latest/com/swmansion/reanimated/layoutReanimation/ReanimatedUIManager.java:141: error: cannot find symbol node_modules/react-native-reanimated/android/src/reactNativeVersionPatch/ReanimatedUIManager/latest/com/swmansion/reanimated/layoutReanimation/ReanimatedUIManager.java:201: error: cannot find symbol node_modules/react-native-reanimated/android/src/reactNativeVersionPatch/ReanimatedUIManager/latest/com/swmansion/reanimated/layoutReanimation/ReanimatedUIManager.java:206: error: cannot find symbol |
Same here |
Same here 0.75.1 |
I got the same error. |
I faced this with React Native react {
/* Variants */
// The list of variants to that are debuggable. For those we're going to
// skip the bundling of the JS bundle and the assets. By default is just 'debug'.
// If you add flavors like lite, prod, etc. you'll have to list your debuggableVariants.
debuggableVariants = ["developmentDebug", "releaseDebug"] |
any update on this ? app is working fine when we run on the device or emulator. when creating debug build or prod build and try to run the app it will crash |
As @binle says, it is fixed in #6420 and will be included in version 3.16.0 I tried out this nightly build and the error is gone |
@appfr3d thanks for the suggestion! Anyway this worked for my app:
|
The nightly builds are working for me on iOS and Android. Is there an ETA for a release of 3.16.0? |
The nightly build does not resolve the problem for me. The app still crashes immediately after launch (but only when it's a standalone APK, not when it's connected to the PC with Metro bundler running). This is what I'm using:
Here are the logs from adb logcat. Looks pretty similar to what the OP posted:
|
expo 51sdk of 0.75.2, same question |
I have created another repro app project that shows this issue is still there even with the latest nightly build. My repro app is more or less identical to the RNRACrashRepro from the OP, but it uses the latest stable version of react-native I was also able to verify once more that the crash only happens with a prod bundle and not with a dev bundle. https://github.com/EmilJunker/RNRACrashRepro See the Readme for instructions to reproduce the crash and for the logs from adb logcat. |
I get the same when trying to create a development build. |
Can confirm that it is still not working with On iOS here and still crashing. |
Bumping down from 75.2 -> 75.1 works for me |
I can't confirm this. The combination Here are the crash logs from adb logcat. Same as always:
|
Same here. Only crash on debug mode. |
same crash for Android 11 on Android 14 it seems to work fine.
|
Also have a very similar problem after thinking everything went fine with Expo 51 😞
Not sure what is the state of "staging app deployed in development but connected to an update", wether it's debug or release, what is sure is it's crashing 😅 haven't tried a non-developement build. Will try the reanimated 3.16 nightly release 🙂 Config:
Android stack trace
iOS stack trace
|
Update: also tried the following combo
All with expo 51.0.32. I still have the error on iOS. I'm building without dev client now, to see what's happening! |
Did anyone actually solve this? Or is there no good (temporary) solution yet? |
AFAIK, There is no solution for this yet. The only obvious workarounds are:
Not sure if there exists a similar workaround for iOS. I must say I find it quite striking that there is no response or acknowledgment from the maintainers about this issue. Is this even being worked on? Has it been assigned to anyone? |
Don't worry, I'm investigating it 😎 |
For me the crash is on prod built package |
…n React Native 0.75 (#6520) ## Summary Currently there seems to be a bug in the JSI layer which causes a crash when we try to copy some of the console methods, i.e. `clear` or `dirxml`. The crash happens only in React Native 0.75. It's not reproducible in neither 0.76 nor 0.74. It also happens only in the configuration of a debug app and production bundle. I haven't yet discovered what exactly causes the crash. It's tied to the console methods sometimes being `HostFunction`s. Therefore, as a workaround we don't copy the methods as they are in the original console object, we copy JavaScript wrappers instead. The fix should't be treated as a complete solution. Same crash could also happen on copying of some other HostFunctions. ## Details 1. In Hermes runtime there's a global `console` object. Reanimated sends methods of this object via JSI to store "references" to them. 2. Sometimes, some of the console methods turn out to be HostFunctions. In this case, we obtain the underlying `std::function` from the `jsi::Function` with `getHostFunction`. 3. We copy the obtained `std::function` and store that copy. This is where the crash happens, on the copy assignment (memory - bad access). Certain conditions have to be met for this flow to occur and for the crash to happen: - It's present only in React Native 0.75.x. I've tried both 0.74 and RC of 0.76 and everything is okay there. - I've been troubleshooting for iOS but allegedly it's platform agnostic. Also, the crash appears on both Paper and Fabric. - When I mentioned that "some of the console methods turn out to be HostFunctions" - this only happens in RN 0.75. In both 0.74 and RC of 0.76 the methods we copy are never HostFunctions. - It's present in configuration of a debug build of the app with a production bundle. In cases of debug&debug or prod&prod there's no crash. - Methods which causes the crash are the more exotic ones - `clear`, `dirxml` etc. They all are HostFunctions when crash conditions are present. Common methods like `log`, `warn` etc. are standard JS functions and can be copied with no issues. I rummaged through Hermes repo to find where i.e. `clear` method originates. I found this file which from I understand creates the "first" console object: https://github.com/facebook/hermes/blob/649ceaa4c8b2ed331251152ccb7fcee07f19fc4c/tools/node-hermes/nodelib/wrappers/internal/console/constructor.js#L470 However, nothing in here suggests that any method should be a HostObject. Therefore I assume it's either replaced somewhere else by Hermes or React Native, i.e. - When Chrome Debug Protocol is connected into the runtime https://github.com/facebook/hermes/blob/649ceaa4c8b2ed331251152ccb7fcee07f19fc4c/API/hermes/inspector/chrome/CDPHandler.cpp#L2372 - Initialization of Hermes, although I assume, `console` object is injected into the global scope for the first time here: https://github.com/facebook/hermes/blob/649ceaa4c8b2ed331251152ccb7fcee07f19fc4c/tools/node-hermes/node-hermes.cpp#L306 On the React Native side, I found the place where they replace the console with some polyfills in debug bundles. Since the bundle is in production mode, this doesn't happen: https://github.com/facebook/react-native/blob/949296571b36080d4ebe0bc8fac9ef3907367475/packages/polyfills/console.js#L596 ## Test plan Apply the following patch to Metro to be able to juggle between bundle types: ```diff diff --git a/src/lib/splitBundleOptions.js b/src/lib/splitBundleOptions.js index 3f35705877cd2d91fc032ea6a75a12b449155ac7..f78656a8c5bdeff4d3915cf2a7262613b6f447ba 100644 --- a/src/lib/splitBundleOptions.js +++ b/src/lib/splitBundleOptions.js @@ -1,15 +1,18 @@ "use strict"; +const overrideBundleType = true; +const isDevBundle = false; + function splitBundleOptions(options) { return { entryFile: options.entryFile, resolverOptions: { customResolverOptions: options.customResolverOptions, - dev: options.dev, + dev: overrideBundleType ? isDevBundle : options.dev, }, transformOptions: { customTransformOptions: options.customTransformOptions, - dev: options.dev, + dev: overrideBundleType ? isDevBundle : options.dev, hot: options.hot, minify: options.minify, platform: options.platform, ``` ## Notes Sorry for the wall of text but this crash is way too annoying to document and screenshot everything thoroughly 🤷 Fixes - #6415
…n React Native 0.75 (#6520) ## Summary Currently there seems to be a bug in the JSI layer which causes a crash when we try to copy some of the console methods, i.e. `clear` or `dirxml`. The crash happens only in React Native 0.75. It's not reproducible in neither 0.76 nor 0.74. It also happens only in the configuration of a debug app and production bundle. I haven't yet discovered what exactly causes the crash. It's tied to the console methods sometimes being `HostFunction`s. Therefore, as a workaround we don't copy the methods as they are in the original console object, we copy JavaScript wrappers instead. The fix should't be treated as a complete solution. Same crash could also happen on copying of some other HostFunctions. ## Details 1. In Hermes runtime there's a global `console` object. Reanimated sends methods of this object via JSI to store "references" to them. 2. Sometimes, some of the console methods turn out to be HostFunctions. In this case, we obtain the underlying `std::function` from the `jsi::Function` with `getHostFunction`. 3. We copy the obtained `std::function` and store that copy. This is where the crash happens, on the copy assignment (memory - bad access). Certain conditions have to be met for this flow to occur and for the crash to happen: - It's present only in React Native 0.75.x. I've tried both 0.74 and RC of 0.76 and everything is okay there. - I've been troubleshooting for iOS but allegedly it's platform agnostic. Also, the crash appears on both Paper and Fabric. - When I mentioned that "some of the console methods turn out to be HostFunctions" - this only happens in RN 0.75. In both 0.74 and RC of 0.76 the methods we copy are never HostFunctions. - It's present in configuration of a debug build of the app with a production bundle. In cases of debug&debug or prod&prod there's no crash. - Methods which causes the crash are the more exotic ones - `clear`, `dirxml` etc. They all are HostFunctions when crash conditions are present. Common methods like `log`, `warn` etc. are standard JS functions and can be copied with no issues. I rummaged through Hermes repo to find where i.e. `clear` method originates. I found this file which from I understand creates the "first" console object: https://github.com/facebook/hermes/blob/649ceaa4c8b2ed331251152ccb7fcee07f19fc4c/tools/node-hermes/nodelib/wrappers/internal/console/constructor.js#L470 However, nothing in here suggests that any method should be a HostObject. Therefore I assume it's either replaced somewhere else by Hermes or React Native, i.e. - When Chrome Debug Protocol is connected into the runtime https://github.com/facebook/hermes/blob/649ceaa4c8b2ed331251152ccb7fcee07f19fc4c/API/hermes/inspector/chrome/CDPHandler.cpp#L2372 - Initialization of Hermes, although I assume, `console` object is injected into the global scope for the first time here: https://github.com/facebook/hermes/blob/649ceaa4c8b2ed331251152ccb7fcee07f19fc4c/tools/node-hermes/node-hermes.cpp#L306 On the React Native side, I found the place where they replace the console with some polyfills in debug bundles. Since the bundle is in production mode, this doesn't happen: https://github.com/facebook/react-native/blob/949296571b36080d4ebe0bc8fac9ef3907367475/packages/polyfills/console.js#L596 ## Test plan Apply the following patch to Metro to be able to juggle between bundle types: ```diff diff --git a/src/lib/splitBundleOptions.js b/src/lib/splitBundleOptions.js index 3f35705877cd2d91fc032ea6a75a12b449155ac7..f78656a8c5bdeff4d3915cf2a7262613b6f447ba 100644 --- a/src/lib/splitBundleOptions.js +++ b/src/lib/splitBundleOptions.js @@ -1,15 +1,18 @@ "use strict"; +const overrideBundleType = true; +const isDevBundle = false; + function splitBundleOptions(options) { return { entryFile: options.entryFile, resolverOptions: { customResolverOptions: options.customResolverOptions, - dev: options.dev, + dev: overrideBundleType ? isDevBundle : options.dev, }, transformOptions: { customTransformOptions: options.customTransformOptions, - dev: options.dev, + dev: overrideBundleType ? isDevBundle : options.dev, hot: options.hot, minify: options.minify, platform: options.platform, ``` ## Notes Sorry for the wall of text but this crash is way too annoying to document and screenshot everything thoroughly 🤷 Fixes - #6415
@tjzel I just updated to Reanimated 3.15.3 (fix is in it), don't have the crash on Android anymore Thanks a lot for your work!!! |
Also fine on iOS, just finished the test! 👌 you guys are the greatest 😀 |
- Facing this issue crashing the app after load software-mansion/react-native-reanimated#6415
- Facing this issue crashing the app after load software-mansion/react-native-reanimated#6415
- Facing this issue crashing the app after load software-mansion/react-native-reanimated#6415
What combo are u using? With this combo builds for iOS but not Android:
|
@gabrielumatch here's what I have: "expo": "~51.0.32", // I should update
"react-native-reanimated": "3.15.3", // same
"react-native": "0.75.2", // 🟡 different! |
For me it's working now with this setup:
|
- Facing this issue crashing the app after load software-mansion/react-native-reanimated#6415
Description
using the latest RN 0.75 RC with Reanimated 3.15.0, I get the following results:
Steps to reproduce
Snack or a link to a repository
https://github.com/Rexogamer/RNRACrashRepro
Reanimated version
3.15.0
React Native version
0.75.0-rc.7
Platforms
Android
JavaScript runtime
Hermes
Workflow
None
Architecture
Reproducible on both
Build type
See description
Device
Real device
Device model
Google Pixel 7 (Android 15 Beta 4.1)
Acknowledgements
Yes
The text was updated successfully, but these errors were encountered: