[iOS] Crash EXC_BREAKPOINT facebook::jsi::detail::BeforeCaller<T>::before #5421
Comments
github-actions
bot
added
the
Missing repro
|
Hey! 👋 The issue doesn't seem to contain a minimal reproduction. Could you provide a snack or a link to a GitHub repository under your username that reproduces the problem? |
github-actions
bot
added
Platform: iOS
|
Hey! 👋 It looks like you've omitted a few important sections from the issue template. Please complete Snack or a link to a repository section. |
|
Thanks for reporting, Nodonisko. We see the same issue in Sentry with the exact same stack trace. It seems to be somewhat rare, but it does result in a fatal crash, so is worth looking into. We use react-native 0.72.6 and react-native-reanimated 3.5.4. I'll update both and if the issue persists for 3.6.0, I'll add a full bug report here. |
Omdat we iOS crashes zien gerelateerd aan reanimated en hermes (https://municipality-of-amsterdam.sentry.io/issues/4576021340/events/4837141d08ed4c80bfd016bb65b26d94), heb ik RN en reanimated ge-update. Ik wil graag even kijken of dit het issue oplost. Zo niet, dan gaan we aanhaken bij de bug report software-mansion/react-native-reanimated#5421 Geen verdere wijzigingen nodig ivm met de RN update (https://github.com/facebook/react-native/releases/tag/v0.72.7) Zie #96660 Related work items: #98495
|
@SpreadTriad we are also getting this same crash with exact same stack trace. |
|
So it looks like that it's happening on app launch? I will try to relaunch app in simulator many times and see if I will be able to replicate that. |
|
Not immediately on app launch, at least not for us. Looking at the Sentry "breadcrumbs", there is some interaction before the crash. But we may have differences in our implementation. In #5331 (comment) a possible cause is mentioned: mixing the RN Animated component with the reanimated version. I'll look into it more next week. @sagar-tomar-groww thank you for sharing! |
|
We do not used RN Animated anywhere, but we use Reanimated with Skia quite a lot. |
|
@SpreadTriad For your reference. Below is the stack trace for us. |
|
For same problem i am getting this stacktrace error from Sentry form quite some time now .
|
|
Hi, we have the same error on our side that appears on iOS regardless of version If it might help, here is the stacktrace on version And below the stacktrace on version Before version |
|
@Nodonisko Thanks for reporting this crash. @sagar-tomar-groww @huextrat Can you please provide full stack trace for all threads and exact versions of the libraries that you are using (Reanimated, Skia, Expo-GL, React Native)? My suspicion is that some other library uses Reanimated runtime on the JS thread while Reanimated tries to use it on the UI thread, hence the crash in the assert. In @arditderstila's stack trace the JS thread is installing ExpoGL. Duplicate of #5331. |
|
Here is the full stack trace @tomekzaw with every threads. We are not using Full Stack TraceOS Version: iOS 17.1.2 (21B101) Report Version: 104Exception Type: EXC_BREAKPOINT (SIGTRAP) Application Specific Information: Thread 0 Crashed: Thread 0 Crashed: Thread 1 Thread 2 Thread 3 Thread 4 name: com.apple.uikit.eventfetch-thread Thread 5 Thread 6 Thread 7 name: SentryCrash Exception Handler (Secondary) Thread 9 Thread 10 Thread 11 Thread 12 name: com.facebook.react.JavaScript Thread 13 Thread 14 name: hades Thread 15 name: hermes-chrome-inspector-conn Thread 16 name: hermes-inspector Thread 17 name: com.apple.NSURLConnectionLoader Thread 18 name: com.apple.CFNetwork.CustomProtocols Thread 19 Thread 20 name: com.facebook.SocketRocket.NetworkThread Thread 21 name: com.apple.CFSocket.private Thread 22 Thread 0 crashed with ARM Thread State (64-bit): |
|
Could this be related to And it seems that react-native-screen uses reanimated. |
|
@huextrat Thanks, this helps a lot! Does the stack trace come from a debug or release build? What's the exact name of the build configuration, is it @Nodonisko Might be, but currently we suspect that the issue is that Reanimated tries to use worklet runtime on the UI thread (e.g. when handling event) when the worklet runtime has not been fully initialized yet. |
@tomekzaw Glad to help! This stack trace is from a release build. If you mean the exact name of iOS configuration, it's |
|
@tomekzaw I think it's also happening on Android, but there is no stacktrace only SIGTRAP https://satoshilabs.sentry.io/share/issue/f556cdefb8f34eecaafe93d7ddbe50c8/ I just noticed we started to get this error on Android right after we updated Reanimated from 2.3.0 to 2.5.4 which is same time as we started to get that iOS error. |
|
@huextrat Great, that's what I thought, thanks for confirming this! You see, the failing code is wrapped inside At the same time, passing |
|
@tomekzaw Thank you for your investigation. There's documentation on the I'm looking forward to seeing the PR! |
This is a flag from React Native (mentioned e.g. here) but yeah it's not documented at all, that's why we shouldn't rely on it. However, it's required only if the build configuration has a different name than the default one, which technically is also a custom setup. |
All right, it would have been interesting to be the same flag as |
|
@tomekzaw Thank you for quick fix! |
<!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please follow the template so that the reviewers can easily understand what the code changes affect. --> ## Summary Fixes #5421, fixes #5331. This PR removes `installValueUnpacker` method which was called on the JS thread during the creation of `NativeReanimatedModule` but operated directly on the UI runtime. Because of this, UI runtime was already used from JS thread so any use from the UI runtime (e.g. Reanimated event handlers) would cause a crash due to a failed check in `ReanimatedReentrancyCheck::before`. Note that the check also occurred in release mode due to improperly set `NDEBUG` flag. ## Test plan <!-- Provide a minimal but complete code snippet that can be used to test out this change along with instructions how to run it and a description of the expected behavior. -->
|
@tomekzaw I seems that fix did not helped, at least for iOS. We released yesterday new version of our app which is using version Same error as before: |
are u using Hermes ? |
|
Yes, it's Hermes. |
Voor issue: #104540 ...willen we de fix doorvoeren voor: software-mansion/react-native-reanimated#5505 (ook software-mansion/react-native-reanimated#5421) ...en die is opgelost in: https://github.com/software-mansion/react-native-reanimated/releases/tag/3.7.0
Description
Hello after update to latest Reanimated from 3.2 to 3.5.4 we started to get quite a lot of crashes in Sentry from production. Full stack trace should be available here: https://satoshilabs.sentry.io/share/issue/b32f6c235e384b0f8703d7ab37b6edfa/
Crashes seems to be random and we were not able to reproduce them yet, but we are pretty sure that this is caused by either Reanimated or @shopify/react-native-skia because we did not any other changes in our latest release except updating these two libraries.
This error seems to be iOS specific, not a single crash from Android so far.
Steps to reproduce
We were not able to reproduce it yet, but I will add example if we will some reliable way how to reproduce it.
Snack or a link to a repository
Reanimated version
3.5.4
React Native version
0.71.8
Platforms
iOS
JavaScript runtime
Hermes
Workflow
React Native
Architecture
Paper (Old Architecture)
Build type
Release mode
Device
Real device
Device model
No response
Acknowledgements
Yes
The text was updated successfully, but these errors were encountered: