Intermittent HadesGC OldGen corruption (EXC_BAD_ACCESS) correlated with low device memory, across unrelated RN app screens

Bug Description

We're seeing an intermittent native crash in production inside Hermes' HadesGC, with no JS-level reproduction found despite significant investigation. Filing here because the crash is inside Hermes' own GC code; we've also raised related data on software-mansion/react-native-reanimated#6859 (linked below) since that thread already tracks a similar signature, and are cross-linking both so neither team assumes the other owns it.

Versions: react-native 0.86.2 (also reproduced on an earlier 3.0.0 build), react-native-reanimated 4.6.0, react-native-worklets 0.12.2, Hermes (bundled with RN), iOS, Fabric/New Architecture.

Crash signatures observed (same structure, different GC phases — appear to be one bug, not three)

hermes::vm::HadesGC::OldGen::sweepNext(bool)
  → incrementalCollect → collectOGInBackground (background `hades` thread)

hermes::vm::HadesGC::MarkAcceptor::acceptHeap(GCCell*, void const*)
  → incrementalMark → incrementalCollect (background `hades` thread)

hermes::vm::HadesGC::OldGen::search(unsigned int)
  → allocSlow (crashes the JS/mutator thread itself, mid-allocation)

All three are EXC_BAD_ACCESS (KERN_INVALID_ADDRESS).

What we've found across 14 aggregated crash sessions (Crashlytics)

• 13 of 14 sessions crashed with under 5% free device memory (median ≈2.55% free); one outlier at 13.4%.
• Device/OS spread rules out a hardware- or version-specific cause: iPhone XR and iPhone 12/12 Mini on iOS 18.4–18.7, through iPhone 16/17 Pro Max on iOS 26.6–27.0. Total device RAM in the sample ranged from ~2 GB to ~10.3 GB — the percentage free, not the absolute device RAM, is what stayed consistent.
• Crashes landed on at least 7 unrelated screens in our app, with time from the last user action to the crash ranging from under a second to over 33 hours (i.e., surfacing after the app sat backgrounded overnight).
• We found and fixed a real bug in our own code (an animation library misuse) that explained some early instances by timing, but the same signature kept recurring afterward on unrelated screens, so that wasn't the (sole) cause.

Related Hermes issues we reviewed

• #982 (setExternalMemoryPressure for native HostObject memory pressure) — relevant background, but doesn't fully solve this even for existing adopters; a Reanimated maintainer noted trying it "with no luck" for their own JSI HostObject caching.
• #1780 (Hades finalizers running on a GC thread, not the allocating thread) — confirmed as intentional design, not a bug, so not directly applicable, but relevant context on Hades' concurrency model.

Neither of the above matches our exact signature or fixes it; we're filing this as a distinct report.

What would help us help you

We don't have a minimal reproduction — the bug is sporadic (roughly 2-3% of concurrent users over a 12-hour production window) and appears tied to ambient memory pressure rather than a specific code path. We're glad to share full symbolicated crash exports, raw device/breadcrumb data, or run an instrumented/diagnostic build against our production traffic if that would help narrow this down, since we can't reliably reproduce it in a local dev environment.

Cross-reference: software-mansion/react-native-reanimated#6859