Closed abgaryanharutyun closed 1 year ago
The issue is valid!
Same here
Same here
Hey, we are facing the same problem. When running on physical devices (ios) we get this crash randomly
Still happens for us @piaskowyk
Still happens in 2.2.3
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?
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 react-native-reanimated@2.2.4
and react-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)
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:
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
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 #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:
navigation.goBack
, navigation.navigate
, navigation.reset
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?
@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?
I don't think so. But we merged the patch to our master branch in our project (will soon release to production)
@pistonsky ,
I don't think so. But we merged the patch to our master branch in our project (will soon release to production)
I took the patch changes. After the changes there is crash happening at this line RCTAssert(_mounting == nil, @"Mouting block is expected to not be set");
. You may already know this, but just a heads up
@VishnuNCS Thanks a lot for letting me know ✊ Then I guess I will extend my patch until some of code owners come help us.
I'm having the same issue with the app freezing up. This has been happening for over a year (see #2244), just haven't gotten around to debugging properly till now.
The UI thread stops and JS thread overloads. The app all but freezes - our underlying PagerView
is the only thing that still works (presumably because it's native). All inputs, animations, API calls, modals, etc stop in their tracks.
When I try to debug, it seems there's a loop around SharableValue
, where it keeps trying to get
the same value.
The calls always succeed (same number – 29), but I can't figure out what's actually calling it.
A lot of these issues seem pretty similar: #1284 #2775 #2244 #2327 @pistonsky's solution doesn't help in my case – not sure if this is just another issue
The culprit has been found! It was down to a weirdly constructed animated gradient I forgot we were using. Posting more info in #2244
I am getting a good few errors like this since I updated to 3.13.1
. @lucasjohnston the fix in https://github.com/software-mansion/react-native-reanimated/issues/2244 that you mentioned, do you think you will be able to get a PR up for it?
Below is the native crash report reported in Sentry
OS Version: iOS 15.3.1 (19D52)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Crashed Thread: 0
Application Specific Information:
N8facebook3jsi7JSErrorE
Thread 0 Crashed:
0 RunBuddyApp 0x200775a28 facebook::jsc::JSCRuntime::checkException
1 RunBuddyApp 0x200776710 facebook::jsc::JSCRuntime::call (JSCRuntime.cpp:1267)
2 RunBuddyApp 0x200631e74 [inlined] facebook::jsi::Function::callWithThis (jsi-inl.h:249)
3 RunBuddyApp 0x200631e74 [inlined] facebook::jsi::Function::callWithThis (jsi-inl.h:256)
4 RunBuddyApp 0x200631e74 [inlined] facebook::jsi::Function::callWithThis<T> (jsi-inl.h:267)
5 RunBuddyApp 0x200631e74 [inlined] reanimated::MutableValue::set::lambda::operator() (MutableValue.cpp:75)
6 RunBuddyApp 0x200631e74 [inlined] std::__1::__invoke<T> (type_traits:3918)
7 RunBuddyApp 0x200631e74 [inlined] std::__1::__invoke_void_return_wrapper<T>::__call<T> (invoke.h:61)
8 RunBuddyApp 0x200631e74 [inlined] std::__1::__function::__alloc_func<T>::operator() (function.h:178)
9 RunBuddyApp 0x200631e74 std::__1::__function::__func<T>::operator() (function.h:352)
10 RunBuddyApp 0x200658174 [inlined] std::__1::__function::__value_func<T>::operator() (function.h:505)
11 RunBuddyApp 0x200658174 [inlined] std::__1::function<T>::operator() (function.h:1182)
12 RunBuddyApp 0x200658174 reanimated::Scheduler::triggerUI (Scheduler.cpp:17)
13 libdispatch.dylib 0x300568920 _dispatch_call_block_and_release
14 libdispatch.dylib 0x30056a66c _dispatch_client_callout
15 libdispatch.dylib 0x300578b6c _dispatch_main_queue_callback_4CF
16 CoreFoundation 0x300ba9d80 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
17 CoreFoundation 0x300b63f58 __CFRunLoopRun
18 CoreFoundation 0x300b77464 CFRunLoopRunSpecific
19 GraphicsServices 0x3382dd388 GSEventRunModal
20 UIKitCore 0x3059c35cc -[UIApplication _run]
21 UIKitCore 0x305741f70 UIApplicationMain
22 RunBuddyApp 0x2004fbf10 main (main.m:7)
23 <unknown> 0x1010a9aa4 <redacted>
Thread 0 Crashed:
0 RunBuddyApp 0x200775a28 facebook::jsc::JSCRuntime::checkException
1 RunBuddyApp 0x200776710 facebook::jsc::JSCRuntime::call (JSCRuntime.cpp:1267)
2 RunBuddyApp 0x200631e74 [inlined] facebook::jsi::Function::callWithThis (jsi-inl.h:249)
3 RunBuddyApp 0x200631e74 [inlined] facebook::jsi::Function::callWithThis (jsi-inl.h:256)
4 RunBuddyApp 0x200631e74 [inlined] facebook::jsi::Function::callWithThis<T> (jsi-inl.h:267)
5 RunBuddyApp 0x200631e74 [inlined] reanimated::MutableValue::set::lambda::operator() (MutableValue.cpp:75)
6 RunBuddyApp 0x200631e74 [inlined] std::__1::__invoke<T> (type_traits:3918)
7 RunBuddyApp 0x200631e74 [inlined] std::__1::__invoke_void_return_wrapper<T>::__call<T> (invoke.h:61)
8 RunBuddyApp 0x200631e74 [inlined] std::__1::__function::__alloc_func<T>::operator() (function.h:178)
9 RunBuddyApp 0x200631e74 std::__1::__function::__func<T>::operator() (function.h:352)
10 RunBuddyApp 0x200658174 [inlined] std::__1::__function::__value_func<T>::operator() (function.h:505)
11 RunBuddyApp 0x200658174 [inlined] std::__1::function<T>::operator() (function.h:1182)
12 RunBuddyApp 0x200658174 reanimated::Scheduler::triggerUI (Scheduler.cpp:17)
13 libdispatch.dylib 0x300568920 _dispatch_call_block_and_release
14 libdispatch.dylib 0x30056a66c _dispatch_client_callout
15 libdispatch.dylib 0x300578b6c _dispatch_main_queue_callback_4CF
16 CoreFoundation 0x300ba9d80 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
17 CoreFoundation 0x300b63f58 __CFRunLoopRun
18 CoreFoundation 0x300b77464 CFRunLoopRunSpecific
19 GraphicsServices 0x3382dd388 GSEventRunModal
20 UIKitCore 0x3059c35cc -[UIApplication _run]
21 UIKitCore 0x305741f70 UIApplicationMain
22 RunBuddyApp 0x2004fbf10 main (main.m:7)
23 <unknown> 0x1010a9aa4 <redacted>
Thread 1
0 libsystem_kernel.dylib 0x36fa01b2c __workq_kernreturn
1 libsystem_pthread.dylib 0x3e337d13c _pthread_wqthread
Thread 2 name: com.apple.uikit.eventfetch-thread
0 libsystem_kernel.dylib 0x36fa01504 mach_msg_trap
1 libsystem_kernel.dylib 0x36fa01b98 mach_msg
2 CoreFoundation 0x300b5f734 __CFRunLoopServiceMachPort
3 CoreFoundation 0x300b63a28 __CFRunLoopRun
4 CoreFoundation 0x300b77464 CFRunLoopRunSpecific
5 Foundation 0x303bbac80 -[NSRunLoop(NSRunLoop) runMode:beforeDate:]
6 Foundation 0x303bfbdb4 -[NSRunLoop(NSRunLoop) runUntilDate:]
7 UIKitCore 0x30593c748 -[UIEventFetcher threadMain]
8 Foundation 0x303c0a3f8 __NSThread__start__
9 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 3 name: com.facebook.react.JavaScript
0 libsystem_kernel.dylib 0x36fa01504 mach_msg_trap
1 libsystem_kernel.dylib 0x36fa01b98 mach_msg
2 CoreFoundation 0x300b5f734 __CFRunLoopServiceMachPort
3 CoreFoundation 0x300b63a28 __CFRunLoopRun
4 CoreFoundation 0x300b77464 CFRunLoopRunSpecific
5 RunBuddyApp 0x2006b2850 +[RCTCxxBridge runRunLoop] (RCTCxxBridge.mm:384)
6 Foundation 0x303c0a3f8 __NSThread__start__
7 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 4 name: JavaScriptCore bmalloc scavenger
0 libsystem_kernel.dylib 0x36fa01f90 __psynch_cvwait
1 libsystem_pthread.dylib 0x3e3384250 _pthread_cond_wait
2 libc++.1.dylib 0x331e55dd8 std::__1::condition_variable::wait
3 JavaScriptCore 0x317d71170 std::__1::condition_variable_any::wait<T>
4 JavaScriptCore 0x317d75940 bmalloc::Scavenger::threadRunLoop
5 JavaScriptCore 0x317d754e0 bmalloc::Scavenger::threadEntryPoint
6 JavaScriptCore 0x317d7699c std::__1::__thread_proxy<T>
7 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 5 name: com.apple.NSURLConnectionLoader
0 libsystem_kernel.dylib 0x36fa01504 mach_msg_trap
1 libsystem_kernel.dylib 0x36fa01b98 mach_msg
2 CoreFoundation 0x300b5f734 __CFRunLoopServiceMachPort
3 CoreFoundation 0x300b63a28 __CFRunLoopRun
4 CoreFoundation 0x300b77464 CFRunLoopRunSpecific
5 CFNetwork 0x301e0850c _CFURLStorageSessionCopyIdentifier
6 Foundation 0x303c0a3f8 __NSThread__start__
7 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 6 name: AVAudioSession Notify Thread
0 libsystem_kernel.dylib 0x36fa01504 mach_msg_trap
1 libsystem_kernel.dylib 0x36fa01b98 mach_msg
2 CoreFoundation 0x300b5f734 __CFRunLoopServiceMachPort
3 CoreFoundation 0x300b63a28 __CFRunLoopRun
4 CoreFoundation 0x300b77464 CFRunLoopRunSpecific
5 AudioSession 0x3133c6304 CADeprecated::GenericRunLoopThread::Entry
6 AudioSession 0x3133cfd60 CADeprecated::CAPThread::Entry
7 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 7 name: com.squareup.SocketRocket.NetworkThread
0 libsystem_kernel.dylib 0x36fa01504 mach_msg_trap
1 libsystem_kernel.dylib 0x36fa01b98 mach_msg
2 CoreFoundation 0x300b5f734 __CFRunLoopServiceMachPort
3 CoreFoundation 0x300b63a28 __CFRunLoopRun
4 CoreFoundation 0x300b77464 CFRunLoopRunSpecific
5 Foundation 0x303bbac80 -[NSRunLoop(NSRunLoop) runMode:beforeDate:]
6 RunBuddyApp 0x2006edeb8 -[_RCTSRRunLoopThread main] (RCTSRWebSocket.m:1620)
7 Foundation 0x303c0a3f8 __NSThread__start__
8 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 8
0 libsystem_kernel.dylib 0x36fa01ae4 __semwait_signal
1 libsystem_c.dylib 0x3169e6efc nanosleep
2 libsystem_c.dylib 0x3169faf38 sleep
3 RunBuddyApp 0x2007d6c38 monitorCachedData (SentryCrashCachedData.c:139)
4 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 9 name: SentryCrash Exception Handler (Secondary)
0 libsystem_kernel.dylib 0x36fa01504 mach_msg_trap
1 libsystem_kernel.dylib 0x36fa01b98 mach_msg
2 libsystem_kernel.dylib 0x36fa0d22c thread_suspend
3 RunBuddyApp 0x2007e3978 handleExceptions (SentryCrashMonitor_MachException.c:258)
4 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 10 name: SentryCrash Exception Handler (Primary)
0 libsystem_kernel.dylib 0x36fa01504 mach_msg_trap
1 libsystem_kernel.dylib 0x36fa01b98 mach_msg
2 RunBuddyApp 0x2007e39a4 handleExceptions (SentryCrashMonitor_MachException.c:266)
3 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 11 name: io.sentry.anr-tracker
0 libsystem_kernel.dylib 0x36fa01ae4 __semwait_signal
1 libsystem_c.dylib 0x3169e6efc nanosleep
2 Foundation 0x303c1ca04 +[NSThread sleepForTimeInterval:]
3 RunBuddyApp 0x2007cafec -[SentryANRTracker detectANRs] (SentryANRTracker.m:67)
4 Foundation 0x303c0a3f8 __NSThread__start__
5 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 12 name: com.apple.CFStream.LegacyThread
0 libsystem_kernel.dylib 0x36fa01504 mach_msg_trap
1 libsystem_kernel.dylib 0x36fa01b98 mach_msg
2 CoreFoundation 0x300b5f734 __CFRunLoopServiceMachPort
3 CoreFoundation 0x300b63a28 __CFRunLoopRun
4 CoreFoundation 0x300b77464 CFRunLoopRunSpecific
5 CoreFoundation 0x300c5fb1c _legacyStreamRunLoop_workThread
6 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 13
0 libsystem_kernel.dylib 0x36fa01b2c __workq_kernreturn
1 libsystem_pthread.dylib 0x3e337d13c _pthread_wqthread
Thread 14 name: Heap Helper Thread
0 libsystem_kernel.dylib 0x36fa01f90 __psynch_cvwait
1 libsystem_pthread.dylib 0x3e3384250 _pthread_cond_wait
2 JavaScriptCore 0x317cf82b0 WTF::ParkingLot::parkConditionallyImpl
3 JavaScriptCore 0x317bb3c38 WTF::Condition::waitUntilUnchecked<T>
4 JavaScriptCore 0x317cc2cdc WTF::Detail::CallableWrapper<T>::call
5 JavaScriptCore 0x317d1e198 WTF::Thread::entryPoint
6 JavaScriptCore 0x317d20af4 WTF::wtfThreadEntryPoint
7 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 15 name: Heap Helper Thread
0 libsystem_kernel.dylib 0x36fa01f90 __psynch_cvwait
1 libsystem_pthread.dylib 0x3e3384250 _pthread_cond_wait
2 JavaScriptCore 0x317cf82b0 WTF::ParkingLot::parkConditionallyImpl
3 JavaScriptCore 0x317bb3c38 WTF::Condition::waitUntilUnchecked<T>
4 JavaScriptCore 0x317cc2cdc WTF::Detail::CallableWrapper<T>::call
5 JavaScriptCore 0x317d1e198 WTF::Thread::entryPoint
6 JavaScriptCore 0x317d20af4 WTF::wtfThreadEntryPoint
7 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 16 name: Heap Helper Thread
0 libsystem_kernel.dylib 0x36fa01f90 __psynch_cvwait
1 libsystem_pthread.dylib 0x3e3384250 _pthread_cond_wait
2 JavaScriptCore 0x317cf82b0 WTF::ParkingLot::parkConditionallyImpl
3 JavaScriptCore 0x317bb3c38 WTF::Condition::waitUntilUnchecked<T>
4 JavaScriptCore 0x317cc2cdc WTF::Detail::CallableWrapper<T>::call
5 JavaScriptCore 0x317d1e198 WTF::Thread::entryPoint
6 JavaScriptCore 0x317d20af4 WTF::wtfThreadEntryPoint
7 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 17 name: Heap Helper Thread
0 libsystem_kernel.dylib 0x36fa01f90 __psynch_cvwait
1 libsystem_pthread.dylib 0x3e3384250 _pthread_cond_wait
2 JavaScriptCore 0x317cf82b0 WTF::ParkingLot::parkConditionallyImpl
3 JavaScriptCore 0x317bb3c38 WTF::Condition::waitUntilUnchecked<T>
4 JavaScriptCore 0x317cc2cdc WTF::Detail::CallableWrapper<T>::call
5 JavaScriptCore 0x317d1e198 WTF::Thread::entryPoint
6 JavaScriptCore 0x317d20af4 WTF::wtfThreadEntryPoint
7 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 18 name: Heap Helper Thread
0 libsystem_kernel.dylib 0x36fa01f90 __psynch_cvwait
1 libsystem_pthread.dylib 0x3e3384250 _pthread_cond_wait
2 JavaScriptCore 0x317cf82b0 WTF::ParkingLot::parkConditionallyImpl
3 JavaScriptCore 0x317bb3c38 WTF::Condition::waitUntilUnchecked<T>
4 JavaScriptCore 0x317cc2cdc WTF::Detail::CallableWrapper<T>::call
5 JavaScriptCore 0x317d1e198 WTF::Thread::entryPoint
6 JavaScriptCore 0x317d20af4 WTF::wtfThreadEntryPoint
7 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 19 name: JSC Heap Collector Thread
0 libsystem_kernel.dylib 0x36fa01f90 __psynch_cvwait
1 libsystem_pthread.dylib 0x3e3384250 _pthread_cond_wait
2 JavaScriptCore 0x317cf82b0 WTF::ParkingLot::parkConditionallyImpl
3 JavaScriptCore 0x317bb3c38 WTF::Condition::waitUntilUnchecked<T>
4 JavaScriptCore 0x317cc2cdc WTF::Detail::CallableWrapper<T>::call
5 JavaScriptCore 0x317d1e198 WTF::Thread::entryPoint
6 JavaScriptCore 0x317d20af4 WTF::wtfThreadEntryPoint
7 libsystem_pthread.dylib 0x3e337d9a0 _pthread_start
Thread 20
0 libsystem_kernel.dylib 0x36fa01b2c __workq_kernreturn
1 libsystem_pthread.dylib 0x3e337d13c _pthread_wqthread
Thread 21
0 libsystem_pthread.dylib 0x3e337ce8c start_wqthread
Thread 22
0 libsystem_kernel.dylib 0x36fa01b2c __workq_kernreturn
1 libsystem_pthread.dylib 0x3e337d13c _pthread_wqthread
EOF
@walterholohan Unfortunately I wasn't able to diagnose the root cause and so can't submit any kind of PR. A component was making frequent calls between the UI and JS threads, and when the JS thread took too long to resolve the entire UI froze up. I ended up just getting rid of the component for now.
This issue seems more prevalent if you are unmounting a more complex screen as well.
I upgraded again to 13.1.0 but instantly saw 40 crashes over a period of a few days. So I had to downgrade to 13.0.0.
Any updates on the original crash
Fatal Exception: facebook::jsi::JSError Exception in HostObject::get(propName:_value): mutex lock failed
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.
same here
@sebarias Do you get the same crash with the latest reanimated version?
Still getting the same error.
"react-native": "0.68.2",
"react-native-reanimated": "2.8.0",
Error:
workletValueSetter@/.../node_modules/react-native-reanimated/src/reanimated2/core.ts (143:0):1:1085
@[native code]
dyld4 config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/usr/lib/libMTLCapture.dylib
terminating with uncaught exception of type facebook::jsi::JSError: Exception in HostObject::get(propName:_value): mutex lock failed: Invalid argument
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.
Hey @TatuUlmanen, did you see any new crashes after enabling Hermes for iOS?
@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.
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:
"react-native": "0.68.2",
"react-native-reanimated": "2.8.0",
"react-native-screens": "3.13.1",
"@react-navigation/bottom-tabs": "6.3.1",
"@react-navigation/devtools": "^6.0.7",
"@react-navigation/elements": "^1.3.3",
"@react-navigation/native": "6.0.10",
"@react-navigation/stack": "6.2.1",
"react-native-gesture-handler": "2.4.2",
Devices are MI8 Android 10/iPhone 7 Here's the sample Sentry logs:
Still getting the same error.
"react-native": "0.68.2", "react-native-reanimated": "2.8.0",
Error:
workletValueSetter@/.../node_modules/react-native-reanimated/src/reanimated2/core.ts (143:0):1:1085 @[native code] dyld4 config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/usr/lib/libMTLCapture.dylib terminating with uncaught exception of type facebook::jsi::JSError: Exception in HostObject::get(propName:_value): mutex lock failed: Invalid argument
For the record, this error appears to be fixed after we changed our code to only unmount a single screen when the user swipes away, as opposed to unmounting an entire stack of screens. Perhaps the issue stemmed from requiring react-native-reanimated to do too much work all at once?
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
Package versions
Affected platforms