react-native-reanimated: [IOS] Random app crash on production build
Description
Getting app crash on random places with reanimated 2
Expected behavior
No crash
Actual behavior & steps to reproduce
Random behaviour
Snack or minimal code example
terminating with uncaught exception of type facebook::jsi::JSError: Exception in HostObject::get(propName:_value): mutex lock failed: Invalid argument
workletValueSetter
[native code]
(lldb)
Package versions
- React Native: 0.64.2
- React Native Reanimated: 2.2.0
- NodeJS: 14
- Xcode: 12.5.1
- Java & Gradle: -
Affected platforms
- Android
- iOS
- Web
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 27
- Comments: 73 (4 by maintainers)
What features your application uses?
We are also experiencing this:
And the reason seems obvious. An unchecked null ptr access. The reanimated code is riddled with unchecked access to pointers and could really need a thorough linting cure.
It even says in the comment
can be null
, yet RNRA just chains calls on it, without anytry..catch
protection.Exact same crash happened on production using
react-native-reanimated@2.2.4
andreact-native-screens@3.9.0
.Not sure if this is relevant (or true), but I have reason to believe screens is related because sentry tells me it happens in a transaction called
RNSScreen
:(crashlytics reports the exact same error message as in https://github.com/software-mansion/react-native-reanimated/issues/2327#issue-981221150)
Any update on this issue?? It’s affecting our production app negatively.
I would be willing to spend time and help fix the issue too if someone can point me in a direction
Still happens on
2.4.1
, when I swipe back in stack. Very rarely, only in production. It says “C++ Exception: N8facebook3jsi7JSErrorE”. Stack trace points toreanimated::Scheduler::triggerUI
I’m using an old react-navigation:In my case it happens when a screen that contains some worklets that are being used in animated styles gets unmounted. I’m hosting my shared values in react context, so that these values can later be accessed by various components on the screen. The context gets erased, along with all components having animated styles, but the worklet is still being called after that.
Fixed with https://github.com/software-mansion/react-native-reanimated/pull/4239, the fix is available since 3.+ versions 🚀
Any updates on this? We are seeing this issue with Hermes enabled, so unlikely it’s due to that. Also noticed that this mostly happens now after XCode 14
If it helps anyone, check the component where you use reanimated/gestures is not rendering more than necessary.
I was running into an issue with quite a lot of freezing, hanging and crashes from having reanimated shared values set with in a FlatList item components. Noticed that there were a lot of unnecessary renders with my FlatList item components and after fixing this, with the use of memorisation, my app has become more stable and have not seen any reported app freezing since.
This might be similar to some of the earlier comments in regards to noticing this issue happens more when mounting/unmounting more complex screens
We’ve RN 0.66 and reanimated 2.3 and the app crash with the issue.EXC_CRASH (SIGABRT): Exception in HostObject::get(propName:_value): mutex lock failed: Invalid argument workletValueSetter@/Users/XXXX/Documents/bancoChile/front/xxx-app/node_modules/react-native-reanimated/src/reanimated2/core.ts (143:0):1:1085
Only affect the IOS SO v. 15.4, 15.4.1, 15.3, 15.5.
It’s quite amusing that we’ve had a day with no crashes AFTER disabling hermes. But it was only a single day with 1 QA guy, maybe it’s a wrong assumption. Not so sure if hermes/jsc is the issue, or that we are even having the same issues.
Spent a week sniffing around in various issues in all repos, the only thing that comes close and looks promising is 2568
Kinda puzzled I guess.
This issue is labeled IOS only, but it happens on android for us too - log is a bit different, but the behavior is the same -> navigate to the screen that has reanimated code -> it crashes sometimes.
It’s kinda possible to somewhat to reproduce the crash: If I navigate to screen that uses reanimated features (useAnimatedStyles/GestureHandler yada yada) right after launching the app (not 100%, but like 70% of the time) it crashes. If I spend some time in app, visit a few different screens, it kinda works until relaunch/background->foreground interaction.
Packages/versions:
Devices are MI8 Android 10/iPhone 7 Here’s the sample Sentry logs:
iOS log here:
Android 10 Log here
Still getting the same error.
Error:
Any updates on the original crash
Fatal Exception: facebook::jsi::JSError Exception in HostObject::get(propName:_value): mutex lock failed
The culprit has been found! It was down to a weirdly constructed animated gradient I forgot we were using. Posting more info in #2244
Appreciate all the work you do. We are working towards v3 right now. Thank you.
We have limited capacity unfortunately 😕 So it is hard to maintain two branches of versions. I really recommend an update to Reanimated 3 because is much more stable than Rea 2.
@RomanTsegelskyi anything else you’ve updated or enabled? I’ve noticed this issue happening for quite some time on even on XCode 13.
@arinjay They have release a new version some hours ago. I’m installing and testing. Hope it is solved in this version.
Any updates here ?
we are experiencing the same issue for months now. The issue happens when clearing multiple screens for the navigation stack.
@hrupesh The application has been stable since. We were getting consistent deadlocks within the first minute of using the app, now nothing.
We were able to get rid of these deadlocks / crashes by enabling Hermes on iOS. So if you haven’t already, try enabling Hermes and see if the problem still persists.
@VishnuNCS Thanks a lot for letting me know ✊ Then I guess I will extend my patch until some of code owners come help us.
Changing line 261 on screenshot above to
fixes the “freeze” problem. I’m thinking to fire a PR for that, we are still testing this solution on our app.
Ran into the same error using:
Same here.
Hey, we are facing the same problem. When running on physical devices (ios) we get this crash randomly