[Reanimated 4.5.0 + Worklets 0.10.0] `EXC_BAD_ACCESS` and `SIGPIPE` errors with Bundle Mode enabled

[unendingblue]

Description

We are noticing new Sentry crashes with Bundle Mode enabled that did not occur on previous versions of Reanimated + Worklets with Bundle Mode disabled.

Based on the Sentry breadcrumbs, the crashes seem to happen when calling runOnJS(callback), where callback is a JS function, inside react-native-gesture-handler tap gestures. This is deduced by the touch event breadcrumbs, and I am not 100% sure runOnJS is at fault. Example:

 const gesture = useTapGesture({
    onActivate: () => {
      runOnJS(callback)();
    },
  });

Important: This is not reproducible. It seems to happen after the app goes from inactive (screen off, background, etc) to active, but not immediately and not at all times.

Sharing short stack traces below, I can provide longer ones if necessary.

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 17 >
KERN_INVALID_ADDRESS at 0x11.
  hermesvm            0x1046974b4  facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::call

SIGPIPE: _msgSend$setClipsToBounds: > estArrayUInt32:
  libsystem_kernel    0x235ff0cd4  mach_msg2_trap
  libsystem_kernel    0x235ff4228  mach_msg_overwrite
  libsystem_kernel    0x235ff4074  mach_msg

I am not sure if this affects Android too.

Steps to reproduce

See description

Snack or a link to a repository

Reanimated version

4.5.0

Worklets version

0.10.0

React Native version

0.85.3

Platforms

iOS

JavaScript runtime

None

Workflow

None

Architecture

None

Reanimated feature flags

None

React Native release level

None

Build type

No response

Device

No response

Host machine

None

Device model

No response

Acknowledgements

No

[github-actions]

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.

[github-actions]

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?

[tjzel]

Hi @unendingblue, thanks for the report. Could you provide more stack traces?

[unendingblue]

hey @tjzel, here are the full stack traces. <redacted name> is our app name.

EXC_BAD_ACCESS

these come from taps on buttons with react-native-gesture-handler (v3) gestures, after the app is foregrounded from an inactive state

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 17 >
KERN_INVALID_ADDRESS at 0x11.
  hermesvm            0x1046974b4  facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::call
  <redacted name>     0x1023936d0  facebook::jsi::Function::call (jsi-inl.h:313)
  <redacted name>     0x1023936d0  facebook::jsi::Function::call (jsi-inl.h:318)
  <redacted name>     0x1023936d0  facebook::jsi::Function::call<T> (jsi-inl.h:326)
  <redacted name>     0x1023936d0  const::lambda::operator() (JSIWorkletsModuleProxy.cpp:458)
  <redacted name>     0x1023936d0  std::__1::__invoke[abi:nqe210106]<T> (invoke.h:87)
  <redacted name>     0x1023936d0  std::__1::__invoke_void_return_wrapper<T>::__call[abi:nqe210106]<T> (invoke.h:342)
  <redacted name>     0x1023936d0  std::__1::__invoke_r[abi:nqe210106]<T> (invoke.h:348)
  <redacted name>     0x1023936d0  std::__1::__function::__func<T>::operator() (function.h:174)
  React               0x1038f28a8  facebook::react::Task::execute
  React               0x1038ef704  facebook::react::RuntimeScheduler_Modern::executeTask
  React               0x1038effa4  facebook::react::RuntimeScheduler_Modern::runEventLoopTick
  React               0x1038efce8  facebook::react::RuntimeScheduler_Modern::runEventLoop
  React               0x10390ecdc  std::__1::__function::__func<T>::operator()
  React               0x1037168a8  facebook::react::tryAndReturnError
  React               0x103713a08  facebook::react::RCTMessageThread::tryFunc
  React               0x1037137d8  facebook::react::RCTMessageThread::runAsync
  CoreFoundation      0x187266ac8  __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__
  CoreFoundation      0x187266794  __CFRunLoopDoBlocks
  CoreFoundation      0x18726879c  __CFRunLoopRun
  CoreFoundation      0x187267548  _CFRunLoopRunSpecificWithOptions
  React               0x103923edc  +[RCTJSThreadManager runRunLoop]
  Foundation          0x184559820  __NSThread__start__
  libsystem_pthread   0x1e6430434  _pthread_start

EXC_BAD_ACCESS: EventQueueProcessor: Unexpected null event payload >
KERN_INVALID_ADDRESS at 0x11.
  hermesvm            0x102b734b4  facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::call
  <redacted name>     0x1008636d0  facebook::jsi::Function::call (jsi-inl.h:313)
  <redacted name>     0x1008636d0  facebook::jsi::Function::call (jsi-inl.h:318)
  <redacted name>     0x1008636d0  facebook::jsi::Function::call<T> (jsi-inl.h:326)
  <redacted name>     0x1008636d0  const::lambda::operator() (JSIWorkletsModuleProxy.cpp:458)
  <redacted name>     0x1008636d0  std::__1::__invoke[abi:nqe210106]<T> (invoke.h:87)
  <redacted name>     0x1008636d0  std::__1::__invoke_void_return_wrapper<T>::__call[abi:nqe210106]<T> (invoke.h:342)
  <redacted name>     0x1008636d0  std::__1::__invoke_r[abi:nqe210106]<T> (invoke.h:348)
  <redacted name>     0x1008636d0  std::__1::__function::__func<T>::operator() (function.h:174)
  React               0x101db28a8  facebook::react::Task::execute
  React               0x101daf704  facebook::react::RuntimeScheduler_Modern::executeTask
  React               0x101daffa4  facebook::react::RuntimeScheduler_Modern::runEventLoopTick
  React               0x101dafce8  facebook::react::RuntimeScheduler_Modern::runEventLoop
  React               0x101dcecdc  std::__1::__function::__func<T>::operator()
  React               0x101bd68a8  facebook::react::tryAndReturnError
  React               0x101bd3a08  facebook::react::RCTMessageThread::tryFunc
  React               0x101bd37d8  facebook::react::RCTMessageThread::runAsync
  CoreFoundation      0x187266ac8  __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__
  CoreFoundation      0x187266794  __CFRunLoopDoBlocks
  CoreFoundation      0x18726879c  __CFRunLoopRun
  CoreFoundation      0x187267548  _CFRunLoopRunSpecificWithOptions
  React               0x101de3edc  +[RCTJSThreadManager runRunLoop]
  Foundation          0x184559820  __NSThread__start__
  libsystem_pthread   0x1e6430434  _pthread_start

SIGPIPE

these happen immediately when the app is foregrounded from an inactive state. the only place where setClipsToBounds is present in our project is from React Native's ScrollView component, but we are using the one exported from react-native-gesture-handler across the board

SIGPIPE: _msgSend$setClipsToBounds: > estArrayUInt32:
  libsystem_kernel    0x235ff0cd4  mach_msg2_trap
  libsystem_kernel    0x235ff4228  mach_msg_overwrite
  libsystem_kernel    0x235ff4074  mach_msg
  CoreFoundation      0x18729e340  __CFRunLoopServiceMachPort
  CoreFoundation      0x18726830c  __CFRunLoopRun
  CoreFoundation      0x187267548  _CFRunLoopRunSpecificWithOptions
  GraphicsServices    0x22c9cf494  GSEventRunModal
  UIKitCore           0x18cf60240  -[UIApplication _run]
  UIKitCore           0x18cecb154  UIApplicationMain
  UIKitCore           0x18d0d7614  -[UIView(UIConstraintBasedLayout) _setContentHuggingPriorities:]
  <redacted name>     0x104f554c0  UIApplicationDelegate.main (AppDelegate.swift)
  <redacted name>     0x104f554c0  AppDelegate.$main (<compiler-generated>:6)
  <redacted name>     0x104f554c0  main (AppDelegate.swift)
  dyld                0x183e75c18  start

[lachtos]

I have also encountered a similar crash, same setup (Reanimated 4.5.0 + Worklets 0.10.0 Bundle Mode)

EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000011
Crashed: com.facebook.react.runtime.JavaScript
0  hermesvm                       0x2f4b4 facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::call(facebook::jsi::Function const&, facebook::jsi::Value const&, facebook::jsi::Value const*, unsigned long) + 140
1  <appname>                      0x5ca0e8 std::__1::__function::__func<worklets::JSIWorkletsModuleProxy::toOptimizedObject(facebook::jsi::Runtime&) const::$_23::operator()(facebook::jsi::Runtime&, facebook::jsi::Value const&, facebook::jsi::Value const (&) [2]) const::'lambda'(facebook::jsi::Runtime&), void (facebook::jsi::Runtime&)>::operator()(facebook::jsi::Runtime&) + 313 (jsi-inl.h:313)
2  React                          0x2768ac facebook::react::Task::execute(facebook::jsi::Runtime&, bool) + 240
3  React                          0x273708 facebook::react::RuntimeScheduler_Modern::executeTask(facebook::jsi::Runtime&, facebook::react::Task&, bool) const + 132
4  React                          0x273fa8 facebook::react::RuntimeScheduler_Modern::runEventLoopTick(facebook::jsi::Runtime&, facebook::react::Task&) + 176
5  React                          0x273cec facebook::react::RuntimeScheduler_Modern::runEventLoop(facebook::jsi::Runtime&) + 112
6  React                          0x292ce0 _ZNSt3__110__function6__funcIZZN8facebook5react13ReactInstanceC1ENS_10unique_ptrINS3_9JSRuntimeENS_14default_deleteIS6_EEEENS_10shared_ptrINS3_18MessageQueueThreadEEENSA_INS3_12TimerManagerEEENS_8functionIFvRNS2_3jsi7RuntimeERKNS3_14JsErrorHandler14ProcessedErrorEEEEPNS3_18jsinspector_modern10HostTargetEENK3$_0clINSF_IFvSI_EEEEEDaT_EUlvE_NS_9allocatorISY_EEFvvEEclEv + 140
7  React                          0x9a8ac facebook::react::tryAndReturnError(std::__1::function<void ()> const&) + 32
8  React                          0x97a0c facebook::react::RCTMessageThread::tryFunc(std::__1::function<void ()> const&) + 24
9  React                          0x977dc ___ZN8facebook5react16RCTMessageThread8runAsyncENSt3__18functionIFvvEEE_block_invoke + 44
10 CoreFoundation                 0x2dacc __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28
11 CoreFoundation                 0x2d798 __CFRunLoopDoBlocks + 396
12 CoreFoundation                 0x2f7a0 __CFRunLoopRun + 2356
13 CoreFoundation                 0x2e54c _CFRunLoopRunSpecificWithOptions + 532
14 React                          0x2a7ee0 +[RCTJSThreadManager runRunLoop] + 252
15 Foundation                     0x8e824 __NSThread__start__ + 732
16 libsystem_pthread.dylib        0x4438 _pthread_start + 136
17 libsystem_pthread.dylib        0x8cc thread_start + 8```

[unendingblue]

@tjzel quick question for when you see this - would swapping over to scheduleOnRN be a potential solution?

[tjzel]

@unendingblue I don't think so, but it wouldn't hurt to try since runOnJS is deprecated.

I couldn't reproduce it on my end, but I have a few ideas on how to diagnose this further. I'll release version 0.10.1 of Worklets later today with these changes.

[unendingblue]

@tjzel sounds good, we'll make a new release with 0.10.1 and see if we can collect more info for you

[Lapz]

@tjzel I was able to reproduce this today with the help of codex and was able to get a min reproduction using

Minimal repro screen

This has two buttons: - **Natural loop**: repeatedly mounts/unmounts a component that schedules many RN callbacks from the UI runtime and forces GC. - **Deterministic batch**: schedules callbacks, then clears `globalThis.__remoteFunctionRegistry` before delivery. This is intentionally destructive, but it isolates the exact stale-registry condition. ```tsx import React, { useCallback, useEffect, useRef, useState } from 'react'; import { Button, Text, View } from 'react-native'; import { scheduleOnRN, scheduleOnUI } from 'react-native-worklets'; declare global { var __remoteFunctionRegistry: | Map unknown> | undefined; } const CALLBACKS_PER_MOUNT = 250; const CALLBACKS_PER_BATCH = 20; function forceRNGC() { globalThis.gc?.(); } function forceUIGC() { scheduleOnUI(() => { 'worklet'; globalThis.gc?.(); }); } function NaturalRaceOwner({ epoch, onDelivered, }: { epoch: number; onDelivered: (marker: string) => void; }) { useEffect(() => { scheduleOnUI(() => { 'worklet'; for (let i = 0; i < CALLBACKS_PER_MOUNT; i += 1) { scheduleOnRN(onDelivered, `natural:${epoch}:${i}`); } globalThis.gc?.(); }); }, [epoch, onDelivered]); return Mounted owner #{epoch}; } export default function WorkletsRemoteFunctionRepro() { const [naturalRunning, setNaturalRunning] = useState(false); const [epoch, setEpoch] = useState(0); const [mounted, setMounted] = useState(true); const [delivered, setDelivered] = useState(0); const deliveredRef = useRef(0); const onDelivered = useCallback((marker: string) => { deliveredRef.current += 1; setDelivered(deliveredRef.current); console.log('delivered', marker); }, []); useEffect(() => { if (!naturalRunning) return; const id = setInterval(() => { setMounted(false); setEpoch((current) => current + 1); forceRNGC(); forceUIGC(); queueMicrotask(() => setMounted(true)); }, 16); return () => clearInterval(id); }, [naturalRunning]); const runDeterministicBatch = useCallback(() => { scheduleOnUI(() => { 'worklet'; for (let i = 0; i < CALLBACKS_PER_BATCH; i += 1) { scheduleOnRN(onDelivered, `cleared-registry:${i}`); } }); queueMicrotask(() => { globalThis.__remoteFunctionRegistry?.clear(); forceRNGC(); }); }, [onDelivered]); return ( Delivered callbacks: {delivered} Natural epoch: {epoch} {mounted && naturalRunning ? ( ) : ( Owner unmounted )} setNaturalRunning((running) => !running)} /> { forceRNGC(); forceUIGC(); }} /> ); } ```

I was able to fix it with the following patch, which basically checks if the JSfunction is not undefined before calling it

Local patch I’m using

This is the local guard I’m testing. It drops stale remote-function calls when toJSValue() no longer resolves to a callable function.

diff --git a/Common/cpp/worklets/NativeModules/JSIWorkletsModuleProxy.cpp b/Common/cpp/worklets/NativeModules/JSIWorkletsModuleProxy.cpp
index 1e335dbb..b78655c5 100644
--- a/Common/cpp/worklets/NativeModules/JSIWorkletsModuleProxy.cpp
+++ b/Common/cpp/worklets/NativeModules/JSIWorkletsModuleProxy.cpp
@@ -452,7 +452,18 @@ jsi::Object JSIWorkletsModuleProxy::toOptimizedObject(jsi::Runtime &rt) const {
         if (!fun.getProperty(rt, "__remoteFunction").isUndefined()) [[likely]] { // NOLINT(readability/braces)
           const auto remoteFunction = extractSerializableOrThrow<SerializableRemoteFunction>(rt, fun);
           jsScheduler->scheduleOnJS([remoteFunction, serializableArgs](jsi::Runtime &rnRuntime) {
-            const auto unpackedFun = remoteFunction->toJSValue(rnRuntime).getObject(rnRuntime).getFunction(rnRuntime);
+            // PATCH (issue #9776): guard against a use-after-free race. The
+            // RNOriginProxy destructor asynchronously schedules
+            // __remoteFunctionRegistry.delete(remoteId) on this same JS queue.
+            // If that delete runs before this pending callback, toJSValue() ->
+            // registry.get(remoteId) returns undefined, and the original
+            // .getObject(rnRuntime) dereferenced it -> EXC_BAD_ACCESS. Skip the
+            // stale call instead of crashing when the target was already freed.
+            const auto funValue = remoteFunction->toJSValue(rnRuntime);
+            if (!funValue.isObject() || !funValue.getObject(rnRuntime).isFunction(rnRuntime)) {
+              return;
+            }
+            const auto unpackedFun = funValue.getObject(rnRuntime).getFunction(rnRuntime);
             if (serializableArgs == nullptr) {
               // fast path for remote function w/o arguments
               unpackedFun.call(rnRuntime);
diff --git a/Common/cpp/worklets/SharedItems/SerializableRemoteFunction.cpp b/Common/cpp/worklets/SharedItems/SerializableRemoteFunction.cpp
index 3b1275af..fe88766f 100644
--- a/Common/cpp/worklets/SharedItems/SerializableRemoteFunction.cpp
+++ b/Common/cpp/worklets/SharedItems/SerializableRemoteFunction.cpp
@@ -59,7 +59,16 @@ void SerializableRemoteFunction::RNOrigin::resolveOrRejectPromise(
     const std::shared_ptr<Serializable> &resolveValue,
     const std::shared_ptr<RuntimeManager> & /*runtimeManager*/) {
   jsScheduler_->scheduleOnJS([resolver = shared_from_this(), resolveValue](jsi::Runtime &rt) {
-    resolver->toJSValue(rt).getObject(rt).getFunction(rt).call(rt, resolveValue->toJSValue(rt));
+    // PATCH (issue #9776): guard against the same use-after-free race as the
+    // scheduleOnRN path. toJSValue() -> registry.get(remoteId) can return
+    // undefined if the RNOriginProxy destructor already ran registry.delete()
+    // on this queue, and the original .getObject(rt) dereferenced it ->
+    // EXC_BAD_ACCESS. Drop the stale resolution instead of crashing.
+    const auto funValue = resolver->toJSValue(rt);
+    if (!funValue.isObject() || !funValue.getObject(rt).isFunction(rt)) {
+      return;
+    }
+    funValue.getObject(rt).getFunction(rt).call(rt, resolveValue->toJSValue(rt));
   });
 }
 
@@ -83,7 +92,15 @@ void SerializableRemoteFunction::WorkletOrigin::resolveOrRejectPromise(
     return;
   }
   workletRuntime->schedule([resolver = shared_from_this(), resolveValue](jsi::Runtime &rt) {
-    resolver->toJSValue(rt).getObject(rt).getFunction(rt).call(rt, resolveValue->toJSValue(rt));
+    // PATCH (issue #9776): guard against a freed/undefined resolver target.
+    // WorkletOrigin::toJSValue dereferences *function_ on the host runtime; if
+    // the owner was torn down the original .getObject(rt) faulted. Drop the
+    // stale resolution instead of crashing.
+    const auto funValue = resolver->toJSValue(rt);
+    if (!funValue.isObject() || !funValue.getObject(rt).isFunction(rt)) {
+      return;
+    }
+    funValue.getObject(rt).getFunction(rt).call(rt, resolveValue->toJSValue(rt));
   });
 }

After applying the patch I was able to get my test case reproduction working, will release it to users later today and see if the issue is gone.