iOS crash: Exception in HostObject::get(propName: __value): mutex lock failed: Invalid argument workletValueSetter

[jacobarvidsson]

Description

We are seeing a lot of fatal crashes in our production app, via crashlytics. Fatal Exception: Facebook::jsi::JSError Exception in HostObject::get(propName: __value): mutex lock failed: Invalid argument workletValueSetter@.../node_modules/ract-native-reanimated/src/reanimated2/core.ts (143, 0)

Expected behavior

Not to crash.

Actual behavior & steps to reproduce

Crashes, usually when app goes into foreground / or background.

Package versions

name	version
react-native	0.66.4
react-native-reanimated	2.9.0

Affected platforms

• [ ] Android
• [x] iOS
• [ ] Web

[github-actions[bot]]

Hey! 👋

The issue doesn't seem to contain a minimal reproduction.

Could you provide a snippet of code, a snack or a link to a GitHub repository that reproduces the problem?

[github-actions[bot]]

Hey! 👋

It looks like you've omitted a few important sections from the issue template.

Please complete Snack or minimal code example section.

[tomekzaw]

Hello @jacobarvidsson! Thanks for submitting the issue. Indeed, we've had some troubles with app crashing on iOS when going into background or foreground in the past, but it takes some patience (and a lot of luck) to reproduce them.

It would be very helpful if you could specify how do you use Reanimated and when exactly the app crashes. Do you have any minimal reproducible example that you can share with us, or at least a full stack trace?

[jacobarvidsson]

Hi! Thanks for the reply. The problem is we can't really reproduce them either, they only show up in our crashlytics as fatal crashes. We use reanimated in around 40 components in our app, all ranging from useAnimatedStyle, gesture handler / scroll handlers and custom worklets for callbacks. I've attached a stacktrace.

Fatal Exception: Facebook::jsi::JSError Exception in HostObject::get(propName: __value): mutex lock failed: Invalid argument workletValueSetter@.../node_modules/ract-native-reanimated/src/reanimated2/core.ts (143, 0)

Order	Target	Stack
0	target-name	FIRCLSProcessRecordAllThreads + 180
1	target-name	FIRCLSProcessRecordAllThreads + 1176
2	target-name	FIRCLSHandler + 48
3	target-name	__FIRCLSExceptionRecord_block_invoke + 92
4	libdispatch.dylib	_dispatch_client_callout + 20
5	libdispatch.dylib	_dispatch_lane_barrier_sync_invoke_and_complete + 56
6.	target-name	FIRCLSExceptionRecord + 204
7	target-name	FIRCLSTerminateHandler() + 580
8	libc++abi.dylib	std::__terminate(void (*)()) + 20
9	libc++abi.dylib	std::terminate() + 64
10	libobjc.A.dylib	objc::DenseMapBase<objc::DenseMap<objc_class*, PendingInitialize*, objc::DenseMapValueInfo<PendingInitialize*>, objc::DenseMapInfo<objc_class*>, objc::detail::DenseMapPair<objc_class*, PendingInitialize*> >, objc_class*, PendingInitialize*, objc::DenseMapValueInfo<PendingInitialize*>, objc::DenseMapInfo<objc_class*>, objc::detail::DenseMapPair<objc_class*, PendingInitialize*> >::FatalCorruptHashTables(objc::detail::DenseMapPair<objc_class*, PendingInitialize*> const*, unsigned int) const + 14
11	libdispatch.dylib	_dispatch_client_callout + 40
12	libdispatch.dylib	_dispatch_main_queue_drain + 928
13	libdispatch.dylib	_dispatch_main_queue_callback_4CF + 44
14	CoreFoundation	CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 16
15	CoreFoundation	__CFRunLoopRun + 2532
16	CoreFoundation	CFRunLoopRunSpecific + 600
17	GraphicsServices	GSEventRunModal + 164
18	UIKitCore	-[UIApplication _run] + 1100
19	UIKitCore	UIApplicationMain + 364
20		main.swift - Line 20 main + 20

[MingaudasVagonis]

We also had a sudden spike in these crashes (400+ per week) after upgrading to 2.8.0+ and then 2.9.0+. The stack trace is the same, although it usually happens when moving from log in to logged in flow, so basically when a few of the screens are unmounted. We were not able to reproduce it though. Using react-native-screens and native stack.

[tomekzaw]

May be related to #2327

[zzorba]

Seeing this as well on version 2.10.0 + RN 70.0. Going to try out the 3.0-rc2 release to see if it helps at all.

[zzorba]

I'm not completely positive, but I suspect this crash (in my situation) was related to the use of a JSI based library. I was updating a SharedValue to mark progress of a database load operation. When I swapped to a library that made use of JSI, this crash became quite prevalent (on IOS, Android seems unaffected by it). Perhaps an issue with the database system (react-native-quick-sqlite), but it makes some sense that this could cause a multi-threading assumption to be violated?

[lucianobracco-geojam]

Any updates on this thread?

[cz2013]

Also happen in

name	version
react-native	0.68.2
react-native-reanimated	2.9.1

[liamxujia]

Also to be solved.

name	version
react-native	0.67.4
react-native-reanimated	2.8.0

[linh81]

Same here

name	version
react-native	0.69.7
react-native-reanimated	2.13.0

The app crashes randomly when reloading the app (maybe around 1 out of 20 times) while running tests on BrowserStack.

[djnewage]

any updates i am running into this same issue

[agestaun]

In my case it happens when calling setRoot from React Native Navigation. It only happens de second time we call it (because the first time we haven't used reanimated yet). This is the flow:

1. The user opens the app. The library is not used yet, because we use it for the list items (swipe to delete), and there are no items.
2. The user starts creating an item.
3. The user finishes the creation, so we call setRoot to display a new bottom tab and display the new item in the list.
4. The app crashes right away after calling set root. This is the exception.

Exception in HostObject::get(propName:_value): mutex lock failed: Invalid argument

workletValueSetter@/Users/ebuilder/jenkins/workspace/im_ia_release_RELEASE-23.1.0/node_modules/react-native-reanimated/src/reanimated2/core.ts (143:0):1:1085 @[native code]

name	version
react-native	0.69.6
react-native-gesture-handler	2.8.0
react-native-reanimated	2.13.0