react-native-reanimated
react-native-reanimated copied to clipboard
software-mansion
[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
- [X] iOS
- [ ] Web
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hey, we are facing the same problem. When running on physical devices (ios) we get this crash randomly
maybe similar: https://github.com/software-mansion/react-native-reanimated/issues/2366
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.
What features your application uses?
- shared values in context :+1:
- portals :-1:
- setting shared value in InteractionManager 😃
- scrollOffset based animations 🎉
- runOnJS 😕
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.
Is the screen where you are seeing the crash your home screen or another screen you navigate to?
I am running into this same issue. In our app, our shared values are also initialized in context on our home screen. We notice this issue whenever we remount the home screen. (from a push notification while the app is already running)
It doesn't happen every time, but it does happen from time to time and crashes the application. Still trying to wrap my head around completely why it happens as well.
As a workaround for now we are considering initializing our shared values outside of the components (using makeMutable) and then also maintaining them. It's not ideal but it might potentially prevent the crash when the screen holding those shared values unmounts.
We are receiving a lot of these after upgrading from 2.2.0 (in all of the new versions 2.2.1, 2.2.2, 2.2.3, 2.3.0+). Also happening only on real devices in production. I managed to catch the crash on xcode (partially cut off, don't know if that will be any help).
Exact same crash happened on production using [email protected] and [email protected].
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)
After upgrading to reanimated 2.3.0 and no longer reseting routes in react-navigation (not sure which one helped), we have gone from around 1000 total of these crashes in multiple releases to 0.
@MingaudasVagonis We are seeing this issue as well in release builds, currently attempting to upgrade to 2.3.0. If you don't mind me asking, what version of react-navigation are you on?
@Moorkell
"@react-navigation/bottom-tabs": "^6.0.9",
"@react-navigation/material-top-tabs": "^6.0.6",
"@react-navigation/native": "^6.0.6",
"@react-navigation/stack": "^6.0.11",
We also had experimented some crashes and screen freeze when navigate back using navigation.popToTop() or navigation.goBack(). The solution, basically, was use of InteractionManager and remove Layout Animations.
Packges:
- react-native-reanimated@^2.3.1
- react-native-gesture-handler@^2.1.0
This issue is still happening on v2.3.1. I have a more detailed crash log here:
Exception in HostObject::get(propName:_value): mutex lock failed: Invalid argument workletValueSetter@/Users/paulrostorp/work/crimson-frog/actions-runner/_work/mobile/mobile/node_modules/react-native-reanimated/src/reanimated2/core.ts (192:0):1:1085 [native code]
I realize this might not fit everyone's situation, but we also started seeing a crash with this error in production builds only, running v2.3.1 of reanimated and using LayoutAnimations. In our use case, we are using our own bridged iOS native module that is running some longer running processes on the background. We noticed this crash coming up before any of the longer processes were even triggered.
Looking at the Swift we wrote for this, I noticed we were signaling to the main thread within our background thread with Dispatch.main.async which is all fine generally speaking but I realized doing that didn't make sense for us.
I won't pretend I know much about what mutex lock means in this context or in any context really but everything I read online seemed to relate back to DispatchQueues and background threads. But the timing of when this dispatch happens and when we needed to run some LayoutAnimation was right inline with each other and the "randomness" of the crash seemed to align with the asynchronous nature of our native module. I also believe I read somewhere that threads work a little bit differently when running in dev vs. production builds.
I could be making all of this up but just going off of what I could, we seemed to have gotten around this crash for our use case after removing the Dispatch.main.async and keeping things in the background thread.
Definitely feels like there is a bug, or at least an opportunity for a more useful error message, however since signaling back to the main thread is a common/often required process.
Same here.
"react-native-reanimated": "2.2.4",
"react-native-navigation": "7.24.3",
Ran into the same error using:
"react-native-reanimated": "2.3.1",
"react-native-screens": "3.10.2",
"@react-navigation/native": "6.0.6",
"@react-navigation/native-stack": "6.2.5",
Exact same crash happened on production using
[email protected]and[email protected].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 #2327 (comment))
Same error here, using:
"react-native-reanimated": "~2.3.1",
"react-native-screens": "~3.10.1",
"@react-navigation/drawer": "^6.1.8",
"@react-navigation/elements": "^1.2.1",
"@react-navigation/native": "^6.0.6",
"@react-navigation/routers": "^6.1.0",
"@react-navigation/stack": "^6.0.11",
Collected crash log:
Version: 2.2.0 (27)
AppStoreTools: 13C90b
AppVariant: 1:iPhone11,8:15
Beta: YES
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: com.xx.xx.xx [2557]
Date/Time: 2022-02-04 16:26:54.0104 +0800
Launch Time: 2022-02-04 15:43:01.8122 +0800
OS Version: iPhone OS 15.2.1 (19C63)
Release Type: User
Baseband Version: 4.02.02
Report Version: 104
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: FRONTBOARD 2343432205
<RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: application<com.moement.moego.business>:28852 exhausted real (wall clock) time allowance of 10.00 seconds
ProcessVisibility: Foreground
ProcessState: Running
WatchdogEvent: scene-update
WatchdogVisibility: Background
WatchdogCPUStatistics: (
"Elapsed total CPU time (seconds): 19.480 (user 19.480, system 0.000), 30% CPU",
"Elapsed application CPU time (seconds): 0.107, 0% CPU"
) reportType:CrashLog maxTerminationResistance:Interactive>
Triggered by Thread: 0
Kernel Triage:
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
Thread 0 name:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00000001b915a66c __psynch_mutexwait + 8
1 libsystem_pthread.dylib 0x00000001f25fc3cc _pthread_mutex_firstfit_lock_wait + 84 (pthread_mutex.c:1414)
2 libsystem_pthread.dylib 0x00000001f260350c _pthread_mutex_firstfit_lock_slow + 240 (pthread_mutex.c:1490)
3 business 0x0000000102952a94 -[RCTEventDispatcher sendEvent:] + 84 (RCTEventDispatcher.mm:124)
4 business 0x0000000102874c00 -[REAEventDispatcher sendEvent:] + 164 (REAEventDispatcher.m:11)
5 business 0x00000001028dd58c __createEventSetter_block_invoke_2 + 260 (RCTComponentData.m:122)
6 business 0x000000010297b028 -[RCTImageView reloadImage] + 224 (RCTImageView.mm:308)
7 business 0x000000010297c34c -[RCTImageView didMoveToWindow] + 136 (RCTImageView.mm:0)
8 UIKitCore 0x00000001842ece78 -[UIView(Internal) _didMoveFromWindow:toWindow:] + 2228 (UIView.m:15964)
9 UIKitCore 0x00000001842ec960 -[UIView(Internal) _didMoveFromWindow:toWindow:] + 924 (UIView.m:15859)
10 UIKitCore 0x00000001841ea0f4 -[UIScrollView _didMoveFromWindow:toWindow:] + 96 (UIScrollView.m:2987)
11 UIKitCore 0x00000001842ec960 -[UIView(Internal) _didMoveFromWindow:toWindow:] + 924 (UIView.m:15859)
12 UIKitCore 0x00000001841ea0f4 -[UIScrollView _didMoveFromWindow:toWindow:] + 96 (UIScrollView.m:2987)
13 UIKitCore 0x00000001842ec960 -[UIView(Internal) _didMoveFromWindow:toWindow:] + 924 (UIView.m:15859)
14 UIKitCore 0x00000001842125cc __45-[UIView(Hierarchy) _postMovedFromSuperview:]_block_invoke + 140 (UIView.m:12304)
15 CoreAutoLayout 0x000000019a7555f8 -[NSISEngine withBehaviors:performModifications:] + 88 (NSISEngine.m:1988)
16 UIKitCore 0x00000001842a2128 -[UIView(Hierarchy) _postMovedFromSuperview:] + 836 (UIView.m:471)
17 UIKitCore 0x00000001841be194 -[UIView(Internal) _addSubview:positioned:relativeTo:] + 2148 (UIView.m:16700)
18 business 0x00000001028bd944 -[RNSScreenContainerView attachScreen:atIndex:] + 212 (RNSScreenContainer.m:130)
19 business 0x00000001028bddf4 -[RNSScreenContainerView updateContainer] + 1072 (RNSScreenContainer.m:170)
20 business 0x00000001028b8c54 -[RNSScreenView setActivityStateOrNil:] + 108 (RNSScreen.m:76)
21 business 0x00000001028dc8d8 __49-[RCTComponentData createPropBlock:isShadowView:]_block_invoke.89 + 228 (RCTComponentData.m:300)
22 business 0x00000001028dca8c __49-[RCTComponentData createPropBlock:isShadowView:]_block_invoke_2.90 + 364 (RCTComponentData.m:318)
23 business 0x00000001028dccec __37-[RCTComponentData setProps:forView:]_block_invoke + 100 (RCTComponentData.m:356)
24 CoreFoundation 0x0000000181bcc714 __NSDICTIONARY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 (NSDictionaryHelpers.m:10)
25 CoreFoundation 0x0000000181be482c -[__NSDictionaryM enumerateKeysAndObjectsWithOptions:usingBlock:] + 208 (NSDictionaryM_Common.h:315)
26 business 0x00000001028dcc68 -[RCTComponentData setProps:forView:] + 124 (RCTComponentData.m:355)
27 business 0x000000010293041c -[RCTUIManager synchronouslyUpdateViewOnUIThread:viewName:props:] + 156 (RCTUIManager.m:1048)
28 business 0x0000000102968490 -[RCTPropsAnimatedNode updateView] + 260 (RCTPropsAnimatedNode.m:75)
29 business 0x0000000102968bb4 -[RCTPropsAnimatedNode performUpdate] + 840 (RCTPropsAnimatedNode.m:139)
30 business 0x000000010295c79c -[RCTAnimatedNode updateNodeIfNecessary] + 264 (RCTAnimatedNode.m:106)
31 business 0x0000000102964c54 0x10277c000 + 2002004
32 CoreFoundation 0x0000000181bcc714 __NSDICTIONARY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 (NSDictionaryHelpers.m:10)
33 CoreFoundation 0x0000000181be482c -[__NSDictionaryM enumerateKeysAndObjectsWithOptions:usingBlock:] + 208 (NSDictionaryM_Common.h:315)
34 business 0x0000000102964708 0x10277c000 + 2000648
35 business 0x0000000102935b18 RCTExecuteOnMainQueue + 44 (RCTUtils.m:258)
36 business 0x000000010296292c -[RCTNativeAnimatedModule eventDispatcherWillDispatchEvent:] + 92 (RCTNativeAnimatedModule.mm:355)
37 business 0x0000000102952b14 -[RCTEventDispatcher sendEvent:] + 212 (RCTEventDispatcher.mm:127)
38 business 0x0000000102874c00 -[REAEventDispatcher sendEvent:] + 164 (REAEventDispatcher.m:11)
39 business 0x0000000102849638 -[RNGestureHandler sendStateChangeEvent:] + 120 (RNGestureHandler.m:0)
40 business 0x0000000102849590 -[RNGestureHandler sendEventsInState:forViewWithTag:withExtraData:] + 352 (RNGestureHandler.m:233)
41 business 0x0000000102849408 -[RNGestureHandler handleGesture:] + 204 (RNGestureHandler.m:194)
42 UIKitCore 0x0000000184212c14 -[UIGestureRecognizerTarget _sendActionWithGestureRecognizer:] + 56 (UIGestureRecognizer.m:136)
43 UIKitCore 0x00000001841dbd48 _UIGestureRecognizerSendTargetActions + 116 (UIGestureRecognizer.m:1481)
44 UIKitCore 0x00000001841a4a94 _UIGestureRecognizerSendActions + 284 (UIGestureRecognizer.m:1520)
45 UIKitCore 0x00000001841de0f8 -[UIGestureRecognizer _updateGestureForActiveEvents] + 636 (UIGestureRecognizer.m:0)
46 UIKitCore 0x0000000184196304 _UIGestureEnvironmentUpdate + 1988 (UIGestureEnvironment.m:206)
47 UIKitCore 0x00000001841ca0b0 -[UIGestureEnvironment _updateForEvent:window:] + 784 (UIGestureEnvironment.m:1332)
48 UIKitCore 0x00000001841d7250 -[UIWindow sendEvent:] + 4428 (UIWindow.m:3265)
49 UIKitCore 0x0000000184387918 -[UIApplication sendEvent:] + 828 (UIApplication.m:11876)
50 UIKitCore 0x00000001841aa464 __dispatchPreprocessedEventFromEventQueue + 7904 (UIEventDispatcher.m:2290)
51 UIKitCore 0x000000018419f250 __processEventQueue + 6760 (UIEventDispatcher.m:2597)
52 UIKitCore 0x00000001841a46fc __eventFetcherSourceCallback + 172 (UIEventDispatcher.m:2669)
53 CoreFoundation 0x0000000181c470d0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1972)
54 CoreFoundation 0x0000000181c57d90 __CFRunLoopDoSource0 + 208 (CFRunLoop.c:2016)
55 CoreFoundation 0x0000000181b92098 __CFRunLoopDoSources0 + 268 (CFRunLoop.c:2053)
56 CoreFoundation 0x0000000181b978a4 __CFRunLoopRun + 820 (CFRunLoop.c:2951)
57 CoreFoundation 0x0000000181bab468 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3268)
58 GraphicsServices 0x000000019d73638c GSEventRunModal + 164 (GSEvent.c:2200)
59 UIKitCore 0x000000018454d088 -[UIApplication _run] + 1100 (UIApplication.m:3493)
60 UIKitCore 0x00000001842cb958 UIApplicationMain + 2092 (UIApplication.m:5046)
61 business 0x000000010278414c main + 88 (main.m:7)
62 dyld 0x0000000103995aa4 start + 520 (dyldMain.cpp:879)
I can reliably reproduce C++ Exception RNSScreen Unhandled N8facebook3jsi7JSErrorE by setting an entering animation as an exiting animation.
<Animated.View exiting={SlideInDown} />
{
"react-native-reanimated": "~2.3.1",
}
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 to
reanimated::Scheduler::triggerUI
I'm using an old react-navigation:
"react-navigation": "^2.18.3",
"react-navigation-stack": "0.7.0",
I'm trying this modification:
void Scheduler::triggerUI() {
scheduledOnUI = false;
while (uiJobs.getSize()) {
auto job = uiJobs.pop();
try {
job();
} catch (...) {
// do nothing
}
}
}
This is still happening for us on 2.4.1. I tried to narrow this down as much as possible but was difficult due to the seemingly random occurrence of the crash.
To help address other theories in this thread, we were still able to produce a crash in these circumstances:
- Using & Not using LayoutAnimations
- Using
navigation.goBack,navigation.navigate,navigation.reset - Using [email protected]
I went into reanimated JS module and console logged some values out within the workletValueSetter code and the animation value that gets printed right before the crash seems to be different every time, meaning there doesn't seem to be a pattern there.
From reanimated's perspective, what is the actual problem with the mutex having an invalid argument? Does this mean an animation can't run/stop? Can it be silently stopped and then this becomes a different bug and not one that's production breaking? What I'm getting at, is there any reason why @pistonsky 's modification above wouldn't suffice?
I'm losing my mind over this bug because of it only appearing in Release builds and the frequency of it's occurrence being almost completely random. Even if I feel like I've made progress working around this issue, there's no way to tell for sure because it can happen 1 of 5 times, or 1 of 30, or 1 of 50, I went 3 hours once without being able to reproduce and then it finally crashed.
We have the exact same problem, with its randomness etc., and it looks like this happens when we use runOnJS (it could be unrelated but I figured at that point it's worth saying/trying everything)
I have a feeling that my patch is causing a freeze now, instead of a crash before. When I face a freeze, I attach iPhone to debugger, pause execution and see this place in code where it loops forever:
Changing line 261 on screenshot above to
dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 100000000));
fixes the "freeze" problem. I'm thinking to fire a PR for that, we are still testing this solution on our app.
@pistonsky,
fixes the "freeze" problem. I'm thinking to fire a PR for that, we are still testing this solution on our app.
Are the changes to related app freeze are merged to main branch?
