[$250] [Sentry: APP-25V] HybridApp iOS EXC_BAD_ACCESS in RuntimeScheduler_Modern::runEventLoopTick

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-25V

Impact (snapshot at filing)

• Users (total since first seen): 1,938
• Events: 4,178
• Users (last 14d, releases 9.3.89–9.3.91): 3
• First seen: 2025-12-05
• Last seen: now (ongoing)
• Platform: iOS, hybrid_app
• App version(s): seen on 9.3.59 through 9.3.91
• Mechanism: mach, fatal

Stack trace (top frames, first-party only)

facebook::react::RuntimeScheduler_Modern::runEventLoopTick
  -> facebook::react::RuntimeScheduler_Modern::runEventLoop
  -> facebook::react::RCTMessageThread::runAsync
  -> RCT JSThread run loop

Suspected cause

RN Fabric/modern scheduler memory corruption or use-after-free on the JS thread during an event-loop tick. Stack is native-only (no app JS frames), so the fix may require a React Native upgrade or platform-team investigation.

Reproduction

Unknown deterministically — fires on the RN JS thread under load on HybridApp iOS. See linked Sentry events.

Related

• Sibling Sentry IDs (if any): none identified
• Prior GH issues: none
• Production scan: releases 9.3.89, 9.3.90, 9.3.91 (2026-06-02)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022061885259834583946
• Upwork Job ID: 2061885259834583946
• Last Price Increase: 2026-06-09

Issue Owner

Current Issue Owner: @mkhutornyi

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022061885259834583946

[MelvinBot]

⚠️ Preliminary analysis (low confidence) — this is a native crash with no first-party JS frames, so treat it as a starting point, not a conclusion.

TL;DR

This is a native memory-safety fault (EXC_BAD_ACCESS, mach, fatal) on React Native's JS thread, surfacing inside the new-architecture event-loop dispatcher RuntimeScheduler_Modern::runEventLoopTick. The captured stack contains only the generic dispatch frames and none of the frames below it — so it can't tell us which task actually faulted.

The most actionable signal is the impact trend: ~1,938 users since 2025-12-05, but only 3 users in the last 14 days (9.3.89–9.3.91). This crash is largely resolved in current releases. Before spending engineering time, confirm it's still occurring at a rate worth chasing — this looks like a decaying long-tail crash.

Why the stack can't pinpoint the cause

runEventLoopTick executes one scheduled JS task, then drains its microtasks, then runs rendering-update callbacks. Both the task execution and the microtask drain wrap JS errors in try/catch — but an EXC_BAD_ACCESS is a native memory fault (SIGSEGV/SIGBUS delivered as a mach exception), which is not a catchable C++ exception, so it terminates the process wherever it was running.

Because Sentry only captured the generic dispatch frames (runEventLoopTick → runEventLoop → RCTMessageThread::runAsync → JS thread run loop) and nothing below them, the offending task/callback isn't identifiable from this report. That signature — a fault surfacing at the dispatch site with no culprit frame — is typical of a use-after-free / heap corruption that originates elsewhere (another thread, a freed callback, a worklet) and only surfaces on the next JS-thread tick.

Investigation details & code references

Mechanism (node_modules/react-native/ReactCommon/react/renderer/runtimescheduler/RuntimeScheduler_Modern.cpp, RN 0.83.1):

• runEventLoop loops over selectTask() and calls runEventLoopTick(runtime, *task) for each.
• runEventLoopTick → executeTask (runs the JS callback via task.execute), then performMicrotaskCheckpoint (runtime.drainMicrotasks()), then updateRendering (runs queued pendingRenderingUpdates_ callbacks).
• executeTask and performMicrotaskCheckpoint both catch (jsi::JSError&) / catch (std::exception&) — neither catches a native memory fault, which is why the process dies here.

This repo already fixes native RN crashes via patches, so a confirmed root cause would likely be fixable here rather than requiring a full RN upgrade — see patches/react-native/details.md:

• patch 037 — Fabric ComponentDescriptorRegistry deadlock (APP-7B2), from [Due for payment 2026-06-04] [Sentry: APP-7B2] HybridApp iOS Fatal App Hang in Fabric ComponentDescriptorRegistry::findComponentDescriptorByHandle_DO_NOT_USE_THIS_IS_BROKEN #91292
• patch 036 — TurboModule event-emitter use-after-free, from [Due for payment 2026-05-29] [$250] Android - Native crash (SIGSEGV) in JavaTurboModule event emitter callback #90623

Neither obviously explains this report though: patch 036 is Android-only (JavaTurboModule.cpp) while this crash is iOS, and patch 037 is a deadlock/hang, not an EXC_BAD_ACCESS. So I can't claim either already fixed it — the recent drop may instead be due to the Hermes heap/GC tuning patches (024/025) reducing memory pressure, or to a change unrelated to a specific fix. I did not verify that link.

Related issues: the issue body reports none, and my scan (gh issue list for iOS / EXC_BAD_ACCESS / RuntimeScheduler / Fabric crash terms) surfaced no clear duplicate.

Suggested next steps (to make this actionable)

1. Confirm it's still live. Pull the Sentry APP-25V event count for builds ≥ 9.3.89 only. If it's effectively flat-lined, this may be closeable / low-priority.
2. Get deeper symbolicated frames for the recent (9.3.89–9.3.91) events — specifically the frames below runEventLoopTick. That's what identifies whether the faulting task is a worklet (react-native-reanimated 4.3.1 / react-native-worklets run on the JS thread), a TurboModule callback, a timer, or a rendering-update callback.
3. Check the recent events' context (device, iOS version, available memory, in-app flow) — a native UAF/corruption crash often correlates with low memory or a specific repeatable flow.

Because the root cause sits in React Native core C++ and the captured stack has no first-party frames, a contributor can't pin a file:line from the current data alone — this likely needs platform-team / RN-core investigation once deeper frames are available.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis (e.g. paste a fuller symbolicated stack from Sentry and I'll re-investigate).

[KJ21-ENG]

Proposal

Please re-state the problem that we are trying to solve in this issue.

HybridApp on iOS is still crashing on the React Native JS thread inside the modern runtime scheduler:

facebook::react::RuntimeScheduler_Modern::runEventLoopTick
facebook::react::RuntimeScheduler_Modern::runEventLoop
facebook::react::RCTMessageThread::runAsync

There are no app JS frames in the crash, so the issue is not a bad screen-level callback. It is a native runtime stability problem in the RN new-architecture/Hermes event loop used by the hybrid app under load.

What is the root cause of that problem?

The app is running React Native 0.83.1 with iOS new architecture and Hermes V1 forced on in the Podfile:

App/package.json

Line 161 in eaaffe3

"react-native": "0.83.1",

App/ios/Podfile

Lines 81 to 84 in eaaffe3

	# ENV Variable enables/disables TurboModules
	ENV['RCT_NEW_ARCH_ENABLED'] = '1';
	# ENV Variable enables/disables Hermes V1
	ENV['RCT_HERMES_V1_ENABLED'] = '1';

On top of upstream RN/Hermes, Expensify carries app-specific Hermes runtime patches that are explicitly not upstream behavior. The relevant patches increase the initial Hermes heap, stop Hermes from releasing unused memory, and force allocInOldGenBeforeTTI on instead of respecting the runtime option:

App/patches/react-native/react-native+0.83.1+024+perf-increase-initial-heap-size.patch

Lines 8 to 12 in eaaffe3

	auto gcConfig = ::hermes::vm::GCConfig::Builder()
	+ .withInitHeapSize(150ll * 1024 * 1024)
	+ .withShouldReleaseUnused(::hermes::vm::kReleaseUnusedNone)
	// Default to 3GB
	.withMaxHeapSize(3072 << 20)

App/patches/react-native/react-native+0.83.1+025+perf-disable-hermes-young-gc-before-tti-reached.patch

Lines 9 to 14 in eaaffe3

	- if (allocInOldGenBeforeTTI) {
	+ // By enabling the `allocInOldGenBeforeTTI` flag, we prevent
	+ // Hermes from running Young-Gen GC before TTI,
	+ // which saves around 150-200ms on initial load.
	+ // Once Old-Gen GC is triggered, it will enable Young-Gen GC again.
	+ if (/*allocInOldGenBeforeTTI*/ true) {

The patch notes confirm this is a local performance optimization, not an upstream RN fix:

App/patches/react-native/details.md

Lines 188 to 198 in eaaffe3

	- Reason: This patch increases the initial heap size of the Hermes runtime. This allows us to disable Hermes Young-Gen Garbage Collection (GC) in a separate patch, which improves initial TTI and app startup time.
	- Upstream PR/issue: This is not intended to be upstreamed, since this is a low-level fix very specific to the Expensify app's requirements.
	- E/App issue: [#76859](https://github.com/Expensify/App/issues/76859)
	- PR introducing patch: [#76154](https://github.com/Expensify/App/pull/76154)
	### [react-native+0.83.1+025+perf-disable-hermes-young-gc-before-tti-reached.patch](react-native+0.83.1+025+perf-disable-hermes-young-gc-before-tti-reached.patch)
	- Reason: This patch disables Hermes Young-Gen Garbage Collection (GC), which improves initial TTI and app startup time, by delaying GC for early allocated memory to the first Old-Gen GC run.
	- Upstream PR/issue: This is not intended to be upstreamed, since this is a low-level fix very specific to the Expensify app's requirements.
	- E/App issue: [#76859](https://github.com/Expensify/App/issues/76859)
	- PR introducing patch: [#76154](https://github.com/Expensify/App/pull/76154)

That combination is the best app-side explanation for a low-frequency EXC_BAD_ACCESS in RuntimeScheduler_Modern::runEventLoopTick: the JS runtime scheduler is executing queued work while Hermes is using non-default startup GC/lifetime behavior. Under HybridApp load/background transitions, the scheduler can tick against runtime state that has already been invalidated or corrupted, and the crash surfaces in RN native code rather than in application JS.

What changes do you think we should make in order to solve the problem?

I would fix this in the RN/Hermes patch layer, not in product JS.

1. Add an iOS-specific guard or rollback for the two Hermes GC tuning patches:

   • stop forcing .withShouldReleaseUnused(::hermes::vm::kReleaseUnusedNone) for iOS release builds, and
   • stop forcing allocInOldGenBeforeTTI to true; respect the upstream allocInOldGenBeforeTTI parameter or gate the optimization behind an Expensify-controlled build flag that can be disabled for HybridApp iOS.

2. Ship the guarded build to TestFlight/internal HybridApp and compare Sentry for APP-25V against the current release baseline. Because this crash is nondeterministic, the success signal should be a release-to-release drop/disappearance of this exact native signature rather than a local reproduction.

3. If the crash continues after reverting the GC tuning, move the same patch-layer work to the next narrow native suspect: backport the upstream RN runtime scheduler fix from the first RN version where RuntimeScheduler_Modern lifetime handling changes, or upgrade RN/Hermes once validated. The important part is to keep this scoped to ReactCommon/react/runtime/hermes/HermesInstance.cpp / runtime scheduler native code rather than adding JS workarounds around random app flows.

Testing plan:

• Build iOS HybridApp ReleaseProduction with the Hermes GC guard disabled/enabled and verify both variants launch.
• Run the existing iOS smoke path through sign-in, chat navigation, background/foreground, and fast navigation while watching native logs for scheduler/runtime assertions.
• Monitor Sentry for APP-25V on the first release containing the guard and compare event count/users against 9.3.89-9.3.91.

What alternative solutions did you explore? (Optional)

I considered proposing a JS-side throttle around heavy HybridApp navigation or Onyx work, but the stack has no JS frames and crashes inside the RN runtime scheduler. That would only hide load patterns, not fix the native memory/lifetime failure.

I also considered a blanket RN upgrade as the primary fix. That may ultimately be needed, but Expensify has a concrete local Hermes runtime deviation that directly affects memory lifetime on the same JS runtime thread. Reverting or gating that local patch is the smaller, testable first change before taking the larger upgrade risk.