[iOS] EXC_BAD_ACCESS in performOperations from handleRawEvent during screen pop on 4.3.1

[mtflud]

Description

iOS production EXC_BAD_ACCESS (KERN_INVALID_ADDRESS at 0x18) crash on react-native-reanimated@4.3.1 + react-native-worklets@0.8.3 + Fabric. The crash signature is structurally identical to #9293 / #9303 (a mount-time deref of a stale view during a reanimated commit) but is triggered through a different upstream path: react-native-screens' per-frame notifyTransitionProgress event during a native-stack screen pop, not the rAF / AnimationFrameBatchinator::flush() path that #9293 OP described.

The registry-locking fix in 4.3.1 (PRs #9308, #9323; release tagged 2026-05-07) resolved one variant we were hitting (chat-list-scroll EXC_BAD_ACCESS in AnimatedPropsRegistry::update). The screen-pop variant in this report is still happening after upgrading to 4.3.1, in line with @florian-deroo's and @LeCiel's post-fix reports in #9293.

Crash flow

Main-thread stack at the moment of segfault (real production crash from a TestFlight 1.0.9 build cut after the 4.3.1 bump):

0   [Redacted]    RCTPerformMountInstructions               (RCTMountingManager.mm)
10  [Redacted]     -[RCTMountingManager performTransaction:]                (:258)
11   [Redacted]     -[RCTMountingManager initiateTransaction:]               (:246)
12  [Redacted]     -[RCTSurfacePresenter schedulerShouldRenderTransactions:] (:307)
14  [Redacted]    facebook::react::Scheduler::uiManagerDidFinishTransaction        (Scheduler.cpp:279)
15  [Redacted]    facebook::react::UIManager::shadowTreeDidFinishTransaction       (UIManager.cpp:637)
16  [Redacted]    facebook::react::ShadowTree::notifyDelegatesOfUpdates            (ShadowTree.cpp:426)
17  [Redacted]    facebook::react::ShadowTreeRegistry::visit                       (ShadowTreeRegistry.cpp:50)
20  [Redacted]    reanimated::ReanimatedModuleProxy::performOperations()           (ReanimatedModuleProxy.cpp:673)
21  [Redacted]    reanimated::ReanimatedModuleProxy::handleRawEvent                (ReanimatedModuleProxy.cpp:619)
22  [Redacted]    -[ReanimatedModule attachReactEventListener:]::block-literal::$_0::operator()
30  [Redacted]    facebook::react::EventListenerContainer::willDispatchEvent
31  [Redacted]    facebook::react::EventDispatcher::dispatchEvent
32  [Redacted]    facebook::react::EventEmitter::dispatchEvent
34  [Redacted]    facebook::react::RNSScreenEventEmitter::onTransitionProgress     (EventEmitters.cpp:315)
35  [Redacted]    -[RNSScreenView notifyTransitionProgress:closing:goingForward:]  (RNSScreen.mm:790)
36  [Redacted]    -[RNSScreen notifyTransitionProgress:closing:goingForward:]      (RNSScreen.mm:1983)
37  QuartzCore CA::Display::DisplayLinkItem::dispatch_
38  QuartzCore CA::Display::DisplayLink::dispatch_items
39  QuartzCore CA::Display::DisplayLink::dispatch_deferred_display_links

• Exception: EXC_BAD_ACCESS (SIGSEGV) / KERN_INVALID_ADDRESS at 0x0000000000000018
• The faulting load is a null+offset deref — classic stale-pointer-to-deallocated-object signature inside the mounting layer.

What we believe is happening

1. The user pops a native-stack screen (react-native-screens@4.25.0, no Reanimated*Stack wrapping — vanilla @react-navigation/native-stack).
2. UIKit's CADisplayLink ticks during the transition.
3. RNSScreen::notifyTransitionProgress fires the Fabric onTransitionProgress event every frame (see RNSScreen.mm:1797 → :635; the call is unconditional, no listener gating).
4. The event flows through EventDispatcher::dispatchEvent → EventListenerContainer::willDispatchEvent → reanimated's listener → ReanimatedModuleProxy::handleRawEvent.
5. Inside handleRawEvent, control reaches performOperations() at line 619 — i.e. either (a) StaticFeatureFlags::ENABLE_SHARED_ELEMENT_TRANSITIONS is disabled at build time so the early-return branch is removed, or (b) a JS handler is registered for onTransitionProgress on this view tag (e.g. via useReanimatedTransitionProgress) and the function fell through past isAnyHandlerWaitingForEvent.
6. performOperations() flushes layoutAnimationFlushRequests_ at line 673 and visits each surface's shadow tree.
7. ShadowTree::notifyDelegatesOfUpdates commits a mount transaction. RCTPerformMountInstructions applies a queued mutation against a RCTViewComponentView whose backing UIView is mid-teardown by the screen pop — null deref.

The mutation being flushed is queued by in-flight withSpring/withTiming animations that have not been cancelled before the unmount transaction runs. We confirmed this empirically: the only application-side mitigation that has stopped the crash so far in our internal testing is draining all SharedValues tied to animated styles in the popping subtree before the transition starts (cancelling animations + gating event-driven worklets via a closing flag on navigation.addListener('beforeRemove')).

Why we think this is a follow-up to #9293, not the same bug

• [iOS Crash] EXC_BAD_ACCESS in ReanimatedModuleProxy::performOperations during AnimationFrameBatchinator::flush (RN 0.85.1 + Reanimated 4.3.0 + worklets 0.8.1, New Architecture) #9293 OP's stack goes through AnimationFrameBatchinator::flush() / WorkletRuntime::runSync (the rAF path). Ours goes through RNSScreenEventEmitter::onTransitionProgress → EventDispatcher::dispatchEvent (the event-dispatch path). The crash site is the same (performOperations → mount → null deref) but the call site of performOperations is different.
• [iOS Crash] EXC_BAD_ACCESS in ReanimatedModuleProxy::performOperations during AnimationFrameBatchinator::flush (RN 0.85.1 + Reanimated 4.3.0 + worklets 0.8.1, New Architecture) #9293 was closed as fixed by 4.3.1. We are on 4.3.1 + worklets 0.8.3 and reproducing the crash with the screen-pop signature.
• In [iOS Crash] EXC_BAD_ACCESS in ReanimatedModuleProxy::performOperations during AnimationFrameBatchinator::flush (RN 0.85.1 + Reanimated 4.3.0 + worklets 0.8.1, New Architecture) #9293 comments, @florian-deroo explicitly notes their crashes happen "while the Main Thread is executing performOperations() and unmounting a focused view (removeFromSuperview -> resignFirstResponder)" — consistent with the screen-pop teardown window described here.

Happy to be told this is the same bug and to comment on #9293 instead — flagging as a separate issue to make the screen-pop path visible.

Steps to reproduce

We do not have a deterministic standalone repro and we cannot reproduce on a developer machine (debug builds, internal staging, simulators, or the same physical device with the same account all fail to trigger). The crash is observed in production telemetry across multiple unrelated users; some users reproduce it 100% of the time on every screen, others never. We have not isolated the personal axis.

Snack or a link to a repository

N/A

Reanimated version

4.3.1

Worklets version

0.8.3

React Native version

0.83.9

Platforms

iOS

JavaScript runtime

Hermes

Workflow

Expo Dev Client

Architecture

New Architecture (Fabric renderer)

Reanimated feature flags

No

React Native release level

Stable

Build type

Release app & production bundle

Device

Real device

Host machine

macOS

Device model

iPhone17,1

Acknowledgements

Yes

[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?

[serjek]

The crash is observed in production telemetry across multiple unrelated users; some users reproduce it 100% of the time on every screen, others never. We have not isolated the personal axis.

Exactly the same happens to us ever since we updated RN 79->84 and switched to gesture handler + reanimated because RN dragging with new architecture became too choppy. Affected users are averaging at ~10% and most of them can reproduce the issue quite constantly.

[alainib]

we get this error a lot since last upgrade. not sure how to fix it
happen only on Iphone user for us, android no

[kiranlak]

Same crash on reanimated 4.5.0 / worklets 0.10.0 (RN 0.86, Expo 57, New Arch, Hermes, iOS release/TestFlight).

EXC_BAD_ACCESS (SIGSEGV) at 0x11. Two threads in worklets/reanimated concurrently:

• Thread 0 (UI): QuartzCore DisplayLink → AnimationFrameQueue executeQueueForProMotion → worklets::WorkletRuntime::runSync → ReanimatedModuleProxy::performOperations → commitUpdates → ShadowTree::commit → YogaLayoutableShadowNode::configureYogaTree (__dynamic_cast).
• Thread 13 (JS, crashed): RuntimeScheduler_Modern::runEventLoop → Task::execute → worklets::JSIWorkletsModuleProxy::toOptimizedObject(...)::$_23 → HermesRuntimeImpl::call → hermes::vm::HandleBase::getHermesValue() ← faults on a freed handle.

Device: iPhone 15 Pro, iOS 18.7.8. This looks like the RN-runtime remote-function lifetime issue fixed in #9789 / #9790 and released in worklets 0.10.1. We've bumped to 0.10.1 and will report back whether it resolves this path.

[AlexNetsov]

We're hitting what looks like a stack-overflow variant of this crash in production, on physical iOS devices only. Same entry path — handleRawEvent → performOperations → commitUpdates — but the crash is a main-thread stack overflow inside cloneShadowTreeWithNewPropsRecursive, not a null deref, and the trigger is active scrolling rather than a screen pop. Filing it here since it may share a root cause; happy to open a separate issue if the maintainers prefer.

Environment

• react-native-reanimated 4.3.1, react-native-worklets 0.8.3
• react-native 0.85.3, New Architecture (Fabric), Hermes
• Expo SDK 56
• Physical iOS devices only, Release builds (never seen in Simulator — plausibly the 1 MB device main-thread stack vs 8 MB in the Simulator)
• Sentry signature: EXC_BAD_ACCESS, Exception 1, Code 1 > Stack overflow in (null)

Conditions (from production telemetry; no minimal repro yet)
The screen has a scroll-driven useAnimatedStyle (a translateY parallax fed by useScrollViewOffset), so every scroll frame produces a Reanimated shadow-tree commit on the main thread. The crash correlates strongly with a React state update mounting an overlay near the root of the tree (a toast) while the user is actively scrolling — i.e. React commits racing the per-frame Reanimated commits.

Our reading of the trace: the onScroll event is processed synchronously on the main thread (UIEventHandler::process → runSyncOnRuntime), commitUpdates → cloneShadowTreeWithNewPropsRecursive recurses once per view-nesting level, and at the top of the trace each level's ShadowNode::clone additionally walks YogaLayoutableShadowNode::updateYogaChildren → adoptYogaChild → ShadowNode::clone → folly::dynamic — consistent with interleaved commits leaving yoga-node owners mismatched, inflating the per-level stack cost until the main-thread stack is exhausted mid-recursion.

Working around it by moving the scroll-driven styles on that screen to the core Animated API with the native driver (no shadow-tree commits per scroll frame).

Full Sentry stack trace

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 2786867592849668631 >
Stack overflow in (null)
  ReactNativeDependencies 0x10237f8ec  folly::dynamic::hash
  ReactNativeDependencies 0x102381b70  std::__1::__hash_table<T>::__emplace_unique_key_args<T>
  ReactNativeDependencies 0x102381b70  std::__1::__hash_table<T>::__emplace_unique_key_args<T>
  ReactNativeDependencies 0x1023818dc  std::__1::unordered_map<T>::unordered_map
  ReactNativeDependencies 0x10237e9a0  folly::dynamic::dynamic
  React               0x103b3365c  facebook::react::ShadowNode::clone
  React               0x103b20018  facebook::react::YogaLayoutableShadowNode::adoptYogaChild
  React               0x103b1f8b4  facebook::react::YogaLayoutableShadowNode::updateYogaChildren
  React               0x103b1fc98  facebook::react::YogaLayoutableShadowNode::YogaLayoutableShadowNode
  React               0x103b1ee68  facebook::react::ViewShadowNode::ViewShadowNode
  React               0x103bb6138  std::__1::__shared_ptr_emplace<T>::__shared_ptr_emplace[abi:ne190102]<T>
  React               0x103bb60e4  std::__1::allocate_shared[abi:ne190102]<T>
  React               0x103bb5968  facebook::react::ConcreteComponentDescriptor<T>::cloneShadowNode
  RNReanimated        0x10296db24  reanimated::cloneShadowTreeWithNewPropsRecursive (ShadowTreeCloner.cpp:54)
  RNReanimated        0x10296da74  reanimated::cloneShadowTreeWithNewPropsRecursive (ShadowTreeCloner.cpp:50)
  [ ... the ShadowTreeCloner.cpp:50 frame repeats many times (Sentry truncates) ... ]
  RNReanimated        0x10296da74  reanimated::cloneShadowTreeWithNewPropsRecursive (ShadowTreeCloner.cpp:50)
  RNReanimated        0x10296dd38  reanimated::cloneShadowTreeWithNewProps (ShadowTreeCloner.cpp:88)
  RNReanimated        0x10299e438  const::lambda::operator() (ReanimatedModuleProxy.cpp:1193)
  React               0x103b439a4  facebook::react::ShadowTree::tryCommit
  React               0x103b43714  facebook::react::ShadowTree::commit
  RNReanimated        0x10299e2b0  reanimated::ReanimatedModuleProxy::commitUpdates::lambda::operator() (ReanimatedModuleProxy.cpp:1187)
  React               0x103b47a54  facebook::react::ShadowTreeRegistry::visit
  RNReanimated        0x102997580  reanimated::ReanimatedModuleProxy::commitUpdates (ReanimatedModuleProxy.cpp:1186)
  RNReanimated        0x10299704c  reanimated::ReanimatedModuleProxy::performOperations (ReanimatedModuleProxy.cpp:719)
  RNReanimated        0x1029b6d28  reanimated::createReanimatedModuleProxy (NativeProxy.mm:49)
  RNReanimated        0x1029a4420  reanimated::jsi_utils::createHostFunction<T>::lambda::operator() (ReaJSIUtils.h:123)
  RNWorklets          0x102634688  std::__1::function<T>::operator() (function.h:772)
  hermesvm            0x10455ad34  std::__1::function<T>::operator()
  hermesvm            0x10455aa6c  facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::HFContext::func
  hermesvm            0x10467a688  hermes::vm::NativeFunction::_nativeCall
  hermesvm            0x104684f88  hermes::vm::Interpreter::handleCallSlowPath
  hermesvm            0x104687300  hermes::vm::Interpreter::interpretFunction<T>
  hermesvm            0x104724570  hermes::vm::Runtime::interpretFunctionImpl
  hermesvm            0x10467a74c  hermes::vm::JSFunction::_callImpl
  hermesvm            0x104679844  hermes::vm::Callable::executeCall3
  hermesvm            0x104731488  hermes::vm::arrayPrototypeForEach
  hermesvm            0x10467a688  hermes::vm::NativeFunction::_nativeCall
  hermesvm            0x104684f88  hermes::vm::Interpreter::handleCallSlowPath
  hermesvm            0x104687300  hermes::vm::Interpreter::interpretFunction<T>
  hermesvm            0x104724570  hermes::vm::Runtime::interpretFunctionImpl
  hermesvm            0x10467a74c  hermes::vm::JSFunction::_callImpl
  hermesvm            0x104679ff0  hermes::vm::BoundFunction::_boundCall
  hermesvm            0x104553540  facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::call
  RNWorklets          0x1026394a8  facebook::jsi::WithRuntimeDecorator<T>::call (decorator.h:987)
  RNWorklets          0x1026043b0  worklets::WorkletRuntime::runSync<T> (WorkletRuntime.h:69)
  RNWorklets          0x102603f10  worklets::runSyncOnRuntime (StableApi.cpp:108)
  RNReanimated        0x10296b848  reanimated::UIEventHandler::process (UIEventHandler.cpp:14)
  RNReanimated        0x10296be80  reanimated::UIEventHandlerRegistry::processEvent (UIEventHandlerRegistry.cpp:84)
  RNReanimated        0x102996cfc  reanimated::ReanimatedModuleProxy::handleEvent (ReanimatedModuleProxy.cpp:545)
  RNReanimated        0x102996cfc  reanimated::ReanimatedModuleProxy::handleRawEvent (ReanimatedModuleProxy.cpp:614)
  RNReanimated        0x1029b4508  -[ReanimatedModule attachReactEventListener:] lambda (ReanimatedModule.mm:65)
  React               0x103b2c6a8  facebook::react::EventListenerContainer::willDispatchEvent
  React               0x103b2ac28  facebook::react::EventDispatcher::dispatchUniqueEvent
  React               0x103b2b7e8  facebook::react::EventEmitter::dispatchUniqueEvent
  React               0x103aec910  facebook::react::ScrollViewEventEmitter::onScroll
  React               0x103b90350  -[RCTScrollViewComponentView scrollViewDidScroll:]
  CoreFoundation      0x18d2908f0  __invoking___
  CoreFoundation      0x18d290774  -[NSInvocation invoke]
  CoreFoundation      0x18d2a6424  -[NSInvocation invokeWithTarget:]
  React               0x103bcf148  -[RCTGenericDelegateSplitter forwardInvocation:]
  CoreFoundation      0x18d290370  ___forwarding___
  CoreFoundation      0x18d29ae5c  __forwarding_prep_0___
  UIKitCore           0x1931fd2ac  -[UIScrollView _notifyDidScroll]
  UIKitCore           0x192e9d3b4  -[UIScrollView setContentOffset:]
  React               0x103b8b6e0  -[RCTEnhancedScrollView setContentOffset:]
  UIKitCore           0x193459aec  -[UIScrollView _smoothScrollSyncWithUpdateTime:]
  UIKitCore           0x19345919c  -[UIScrollView _smoothScrollWithUpdateTime:]
  UIKitCore           0x1934590ac  -[UIScrollView _smoothScrollDisplayLink:]
  QuartzCore          0x18dcdc778  CA::Display::DisplayLinkItem::dispatch_
  QuartzCore          0x18dcb4384  CA::Display::DisplayLink::dispatch_items
  QuartzCore          0x18dccb2b4  CA::Display::DisplayLink::dispatch_deferred_display_links
  UIKitCore           0x192f2e2a4  _UIUpdateSequenceRunNext
  UIKitCore           0x192f2b830  schedulerStepScheduledMainSectionContinue
  UpdateCycle         0x2a20d9568  UC::DriverCore::continueProcessing
  CoreFoundation      0x18d2cd354  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
  CoreFoundation      0x18d2cd2c8  __CFRunLoopDoSource0
  CoreFoundation      0x18d2925a4  __CFRunLoopDoSources0
  CoreFoundation      0x18d25c19c  __CFRunLoopRun
  CoreFoundation      0x18d25b548  _CFRunLoopRunSpecificWithOptions

Can share additional Sentry event data (device models, iOS versions, frequency) if useful.