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

[db-flutterwave]

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

• Garbage Collector not picking up high memory pressure when memory is allocated in native HostObjects #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.
• Thread boundaries broken in Hades #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

[lavenzg]

Thanks for reporting this. Could you provide the symbolicated crash trace for the above three crash signatures?

[lavenzg]

@db-flutterwave > react-native 0.86.2 (also reproduced on an earlier 3.0.0 build),
What do you mean by 3.0.0 build? Does it happen on all older version of RN that uses hermes-v1?

[db-flutterwave]

@lavenzg Sorry for the confusion earlier on the "3.0.0" reference, I've struck it from the original post. It was our own app's product version from a staging build, not a React Native version comparison, and it didn't add anything useful to this report, so it shouldn't have been there.

Attaching the symbolicated traces you asked for, for two of the three signatures:

• hermes-2190-trace-OldGen-sweepNext.txt — full crash export (all threads) for the HadesGC::OldGen::sweepNext signature.
• hermes-2190-trace-MarkAcceptor-acceptHeap.txt the crashed thread for the HadesGC::MarkAcceptor::acceptHeap signature, pulled from our production data.

I don't have a usable trace for the third signature (OldGen::search → allocSlow) right now - the original export for that one was removed on our end before I realized we'd need it again. If it'd help, I can try to get a fresh one from Crashlytics and follow up separately.

[lavenzg]

@lavenzg Sorry for the confusion earlier on the "3.0.0" reference, I've struck it from the original post. It was our own app's product version from a staging build, not a React Native version comparison, and it didn't add anything useful to this report, so it shouldn't have been there.

Attaching the symbolicated traces you asked for, for two of the three signatures:

• hermes-2190-trace-OldGen-sweepNext.txt — full crash export (all threads) for the HadesGC::OldGen::sweepNext signature.
• hermes-2190-trace-MarkAcceptor-acceptHeap.txt the crashed thread for the HadesGC::MarkAcceptor::acceptHeap signature, pulled from our production data.

I don't have a usable trace for the third signature (OldGen::search → allocSlow) right now - the original export for that one was removed on our end before I realized we'd need it again. If it'd help, I can try to get a fresh one from Crashlytics and follow up separately.

Thanks for providing these. I checked that RN 0.86.2 still uses hermes tag 250829098.0.16, which is not a new release. Did you see the same crashes before or it only appeared recently? When did you start to observe these crashes? This may help us identify suspicious commits in a matching time window. Thanks!

[julwhitney13]

hi!! i am seeing this on React Native 0.81.5 (hermes-engine pod 0.81.5, New Architecture / Fabric enabled), iOS only

four new signatures, each a single occurrence so far, all first seen within a 48-hour window (2026-09-17 to 2026-09-19) if that’s helpful:

• hermes::vm::GCScope::_newChunkAndPHV
• hermes::vm::IdentifierTable::getSymbolHandleFromPrimitive (via arrayPrototypeMap / objectEntries)
• hermes::vm::hermesBuiltinArraySpread
• hermes::vm::detail::TransitionMap::uncleanMakeLargereached via a TurboModule NSException→JSError conversion, matching the pattern in react-native-new-architecture#276

all four had 5-9% of total device memory free at crash time, consistent with the low-memory correlation described above. Device models: iPhone14,5 / 14,7 / 15,2 / 15,4 / 17,1 / 17,2

for volume - its low - we've got 6k active users / week, and like 10 users got this

Happy to provide (sanitized) full crash exports for any of these if useful

[db-flutterwave]

@lavenzg we recently upgraded our app's react native version from 0.79.0 to 0.86.2 it was after this upgrade that we started to notice this. We just upgraded upgraded last week Monday.

[lavenzg]

hi!! i am seeing this on React Native 0.81.5 (hermes-engine pod 0.81.5, New Architecture / Fabric enabled), iOS only

four new signatures, each a single occurrence so far, all first seen within a 48-hour window (2026-09-17 to 2026-09-19) if that’s helpful:

• hermes::vm::GCScope::_newChunkAndPHV
• hermes::vm::IdentifierTable::getSymbolHandleFromPrimitive (via arrayPrototypeMap / objectEntries)
• hermes::vm::hermesBuiltinArraySpread
• hermes::vm::detail::TransitionMap::uncleanMakeLargereached via a TurboModule NSException→JSError conversion, matching the pattern in react-native-new-architecture#276

all four had 5-9% of total device memory free at crash time, consistent with the low-memory correlation described above. Device models: iPhone14,5 / 14,7 / 15,2 / 15,4 / 17,1 / 17,2

for volume - its low - we've got 6k active users / week, and like 10 users got this

Happy to provide (sanitized) full crash exports for any of these if useful

These issues only started to appear on RN 0.81.5, not on previous versions? The first crash function only touches native heap. Could you provide full crash exports for these?

[julwhitney13]

@lavenzg yep on RN 0.81.5 only: we've been pinned at exactly 0.81.5 since october 2025, but this only started happening after our newest release on wednesday. the only runtime dependency we updated this release was nanoid (5.1.6 → 5.1.16).

crash reports (weve had 7 more since i last commented):

1. GCScope::_newChunkAndPHV event 42192b74…

EXC_BAD_ACCESS:  p@L_ >
KERN_INVALID_ADDRESS at 0x4008000000000000 (= 3.0 as IEEE-754 double)
Crashed thread (`com.facebook.react.runtime.JavaScript`, thread 2 of 16):
at _pthread_start
at NSThread__start
at +[RCTJSThreadManager runRunLoop]
at _CFRunLoopRunSpecificWithOptions
at __CFRunLoopRun
at __CFRunLoopDoBlocks
at CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK
at facebook::react::RCTMessageThread::runAsync
at facebook::react::RCTMessageThread::tryFunc
at facebook::react::tryAndReturnError
at std::__1::__function::__func<T>::operator()
at facebook::react::RuntimeScheduler_Modern::runEventLoop
at facebook::react::RuntimeScheduler_Modern::runEventLoopTick
at facebook::react::RuntimeScheduler_Modern::performMicrotaskCheckpoint
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::drainMicrotasks
at hermes::vm::Runtime::drainJobs
at hermes::vm::Callable::executeCall0
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::JSArray::createNoAllocPropStorage
at hermes::vm::JSArray::createNoAllocPropStorage
at hermes::vm::GCScope::_newChunkAndPHV
Both `HadesGC::Executor::worker` threads (3 and 4) were idle on `condition_variable::wait` at crash time — not actively collecting:
at _pthread_start
at std::__1::__thread_proxy[abi:nn180100]<T>
at hermes::vm::HadesGC::Executor::worker
at std::__1::condition_variable::wait
at _pthread_cond_wait
at __psynch_cvwait

Main thread (0) was idle in its runloop, waiting on mach_msg.

Device/OS: iPhone17,1, iOS 26.6.2 (build 23G90), 8.0GB device, 761MB free (9.5%) at 1. handled: no, level: fatal, mechanism: mach`.

2. GCScope::_newChunkAndPHV, second occurrence event d107a859…

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 734705971359068738
KERN_INVALID_ADDRESS at 0xa32333035373242
Crashed thread (`com.facebook.react.runtime.JavaScript`, thread 5 of 17):
at _pthread_start
at NSThread__start
at +[RCTJSThreadManager runRunLoop]
at _CFRunLoopRunSpecificWithOptions
at __CFRunLoopRun
at __CFRunLoopDoBlocks
at CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK
at facebook::react::RCTMessageThread::runAsync
at facebook::react::RCTMessageThread::tryFunc
at facebook::react::tryAndReturnError
at std::__1::__function::__func<T>::operator()
at facebook::react::RuntimeScheduler_Modern::runEventLoop
at facebook::react::RuntimeScheduler_Modern::runEventLoopTick
at facebook::react::RuntimeScheduler_Modern::performMicrotaskCheckpoint
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::drainMicrotasks
at hermes::vm::Runtime::drainJobs
at hermes::vm::Callable::executeCall0
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::arrayPrototypeMap
at hermes::vm::Callable::executeCall3
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::arrayPrototypeMap
at hermes::vm::Callable::executeCall3
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::functionPrototypeCall
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::objectPrototypeHasOwnProperty
at hermes::vm::objectHasOwnHelper
at hermes::vm::objectHasOwnHelper
at hermes::vm::GCScope::_newChunkAndPHV

Device/OS: iPhone14,7, iOS 26.6.1 (build 23G83), 5.99GB device, 452MB free (7.5%). A

3. GCScope::_newChunkAndPHV, third occurrence event 88d2f53a…

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 0
Attempted to dereference null pointer.
Crashed thread (`com.facebook.react.runtime.JavaScript`, thread 2 of 18):
at _pthread_start
at NSThread__start
at +[RCTJSThreadManager runRunLoop]
at _CFRunLoopRunSpecificWithOptions
at __CFRunLoopRun
at __CFRunLoopDoBlocks
at CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK
at facebook::react::RCTMessageThread::runAsync
at facebook::react::RCTMessageThread::tryFunc
at facebook::react::tryAndReturnError
at std::__1::__function::__func<T>::operator()
at facebook::react::RuntimeScheduler_Modern::runEventLoop
at facebook::react::RuntimeScheduler_Modern::runEventLoopTick
at facebook::react::RuntimeScheduler_Modern::performMicrotaskCheckpoint
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::drainMicrotasks
at hermes::vm::Runtime::drainJobs
at hermes::vm::Callable::executeCall0
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::arrayPrototypeMap
at hermes::vm::Callable::executeCall3
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::arrayPrototypeMap
at hermes::vm::Callable::executeCall3
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::functionPrototypeCall
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::objectPrototypeHasOwnProperty
at hermes::vm::objectPrototypeHasOwnProperty
at hermes::vm::GCScope::_newChunkAndPHV

Device/OS: iPhone18,2, iOS 26.7 (build 23H24), 12.26GB device, 449MB free (3.7%). App: 1.4.8+631.

4. IdentifierTable::getSymbolHandleFromPrimitive event 44822a

EXC_BAD_ACCESS:  p@L_ >
KERN_INVALID_ADDRESS at 0x4
Crashed thread (`com.facebook.react.runtime.JavaScript`, thread 4 of 12):
at _pthread_start
at NSThread__start
at +[RCTJSThreadManager runRunLoop]
at _CFRunLoopRunSpecificWithOptions
at __CFRunLoopRun
at __CFRunLoopDoBlocks
at CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK
at facebook::react::RCTMessageThread::runAsync
at facebook::react::RCTMessageThread::tryFunc
at facebook::react::tryAndReturnError
at std::__1::__function::__func<T>::operator()
at facebook::react::RuntimeScheduler_Modern::runEventLoop
at facebook::react::RuntimeScheduler_Modern::runEventLoopTick
at facebook::react::RuntimeScheduler_Modern::performMicrotaskCheckpoint
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::drainMicrotasks
at hermes::vm::Runtime::drainJobs
at hermes::vm::Callable::executeCall0
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::arrayPrototypeMap
at hermes::vm::Callable::executeCall3
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::arrayPrototypeMap
at hermes::vm::Callable::executeCall3
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::objectEntries
at hermes::vm::enumerableOwnProperties_RJS
at hermes::vm::JSObject::getOwnComputedPrimitiveDescriptor
at hermes::vm::JSObject::getOwnComputedPrimitiveDescriptor
at hermes::vm::IdentifierTable::getSymbolHandleFromPrimitive

Device/OS: iPhone15,4, iOS 26.6.1 (build 23G83), 5.96GB device, 124MB free (2.1%). A

5. hermesBuiltinArraySpread event 80a23895…

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 734705971359068730
KERN_INVALID_ADDRESS at 0xa3233303537323a
Crashed thread (`com.facebook.react.runtime.JavaScript`, thread 6 of 17):
at _pthread_start
at NSThread__start
at +[RCTJSThreadManager runRunLoop]
at _CFRunLoopRunSpecificWithOptions
at __CFRunLoopRun
at __CFRunLoopDoBlocks
at CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK
at facebook::react::RCTMessageThread::runAsync
at facebook::react::RCTMessageThread::tryFunc
at facebook::react::tryAndReturnError
at std::__1::__function::__func<T>::operator()
at facebook::react::RuntimeScheduler_Modern::runEventLoop
at facebook::react::RuntimeScheduler_Modern::runEventLoopTick
at facebook::react::RuntimeScheduler_Modern::performMicrotaskCheckpoint
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::drainMicrotasks
at hermes::vm::Runtime::drainJobs
at hermes::vm::Callable::executeCall0
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::implCallBuiltin
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::hermesBuiltinArraySpread

Device/OS: iPhone15,2, iOS 26.6.1 (build 23G83), 5.93GB device, 330MB free (5.6%). App: 1.4.8+631.

6. TransitionMap::uncleanMakeLarge event 73a80f81…

EXC_BAD_ACCESS: last >
KERN_INVALID_ADDRESS at 0xe0000000e
Crashed thread (thread 1 of 17, unnamed — a dispatch worker, not the JS thread):
at _pthread_wqthread
at _dispatch_workloop_worker_thread
at _dispatch_root_queue_drain_deferred_wlh
at _dispatch_lane_invoke
at _dispatch_lane_serial_drain
at _dispatch_client_callout
at _dispatch_call_block_and_release
at std::__1::__function::__func<T>::operator()
at facebook::react::ObjCTurboModule::performVoidMethodInvocation
at facebook::react::TurboModuleConvertUtils::convertNSExceptionToJSError
at facebook::jsi::Object::setProperty<T>
at facebook::jsi::Object::setProperty<T>
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::setPropertyValue
at hermes::vm::JSObject::putComputedWithReceiver_RJS
at hermes::vm::JSObject::addOwnProperty
at hermes::vm::JSObject::addOwnPropertyImpl
at hermes::vm::HiddenClass::addProperty
at hermes::vm::detail::TransitionMap::insertNew
at hermes::vm::detail::TransitionMap::uncleanMakeLarge

Device/OS: iPhone14,5, iOS 26.6.2 (build 23G90), 3.84GB device, 261MB free (6.8%). A

7. HiddenClass::addProperty event 8305e2f9…

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 16
KERN_INVALID_ADDRESS at 0x10.
Crashed thread (thread 12 of 17, unnamed):
at _pthread_wqthread
at _dispatch_workloop_worker_thread
at _dispatch_root_queue_drain_deferred_wlh
at _dispatch_lane_invoke
at _dispatch_lane_serial_drain
at _dispatch_client_callout
at _dispatch_call_block_and_release
at std::__1::__function::__func<T>::operator()
at facebook::react::ObjCTurboModule::performVoidMethodInvocation
at facebook::react::TurboModuleConvertUtils::convertNSExceptionToJSError
at facebook::jsi::Object::setProperty<T>
at facebook::jsi::Object::setProperty<T>
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::setPropertyValue
at hermes::vm::JSObject::putComputedWithReceiver_RJS
at hermes::vm::JSObject::addOwnProperty
at hermes::vm::JSObject::addOwnPropertyImpl
at hermes::vm::HiddenClass::addProperty

Device/OS: iPhone18,1, iOS 26.7 (build 23H24), 12.29GB device, 1.0GB free (8.1%). App: 1.4.8+631.

8. DictPropertyMap::lookupEntryFor event 0fd8ad78… — involves Worklets module

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 67108900
KERN_INVALID_ADDRESS at 0x4000024.
Crashed thread (`com.facebook.react.runtime.JavaScript`, thread 3 of 18):
at _pthread_start
at NSThread__start
at +[RCTJSThreadManager runRunLoop]
at _CFRunLoopRunSpecificWithOptions
at __CFRunLoopRun
at __CFRunLoopDoBlocks
at CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK
at facebook::react::RCTMessageThread::runAsync
at facebook::react::RCTMessageThread::tryFunc
at facebook::react::tryAndReturnError
at std::__1::__function::__func<T>::operator()
at facebook::react::RuntimeScheduler_Modern::runEventLoop
at facebook::react::RuntimeScheduler_Modern::runEventLoopTick
at facebook::react::RuntimeScheduler_Modern::performMicrotaskCheckpoint
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::drainMicrotasks
at hermes::vm::Runtime::drainJobs
at hermes::vm::Callable::executeCall0
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::arrayPrototypeMap
at hermes::vm::Callable::executeCall3
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::HFContext::func
at std::__1::function<T>::operator()
at std::__1::__function::__func<T>::operator() (function.h:319)
at std::__1::__function::__alloc_func<T>::operator()[abi:ne200100] (function.h:167)
at std::__1::__invoke_r[abi:ne200100]<T> (invoke.h:273)
at std::__1::__invoke_void_return_wrapper<T>::__call[abi:ne200100]<T> (invoke.h:243)
at std::__1::__invoke[abi:ne200100]<T> (invoke.h:179)
at worklets::JSIWorkletsModuleProxy::get::lambda::operator() (JSIWorkletsModuleProxy.cpp:339)
at worklets::makeSerializableObject (Serializable.cpp:183)
at worklets::SerializableJSRef::newNativeStateObject (Serializable.h:119)
at facebook::jsi::Object::setProperty<T> (jsi-inl.h:133)
at facebook::jsi::Object::setProperty<T> (jsi-inl.h:140)
at facebook::jsi::Object::setPropertyValue (jsi.h:1118)
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::setPropertyValue
at hermes::vm::JSObject::putComputedWithReceiver_RJS
at hermes::vm::JSObject::getComputedPrimitiveDescriptor
at hermes::vm::HiddenClass::findProperty
at hermes::vm::DictPropertyMap::lookupEntryFor
This is the first stack in this batch naming a specific third-party module — react-ns — as the entry point into the same property/hidden-class machinery hit by threeother crashes here (`HiddenClass::addProperty` x2, `JSObject::addOwnPropertyImpl`, `JSProxy::defineOwnProperty`).

Device/OS: iPhone17,1, iOS 26.6.2 (build 23G90), 8.0GB device, 516MB free (6.4%). App: 1.4.8+631.

9. JSObject::addOwnPropertyImpl event 7901bf92…

EXC_BAD_ACCESS: namep (a(
KERN_INVALID_ADDRESS at 0x100000012.
Crashed thread (thread 14 of 18, unnamed):
at _pthread_wqthread
at _dispatch_workloop_worker_thread
at _dispatch_root_queue_drain_deferred_wlh
at _dispatch_lane_invoke
at _dispatch_lane_serial_drain
at _dispatch_client_callout
at _dispatch_call_block_and_release
at std::__1::__function::__func<T>::operator()
at facebook::react::ObjCTurboModule::performVoidMethodInvocation
at facebook::react::TurboModuleConvertUtils::convertNSExceptionToJSError
at facebook::jsi::Object::setProperty<T>
at facebook::jsi::Object::setProperty<T>
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::setPropertyValue
at hermes::vm::JSObject::putComputedWithReceiver_RJS
at hermes::vm::JSObject::addOwnProperty
at hermes::vm::JSObject::addOwnPropertyImpl

Device/OS: iPhone16,2, iOS 26.6.2 (build 23G90), 8.03GB device, 406MB free (5.1%). App: 1.4.8+631.

10. JSProxy::defineOwnProperty event f81e3a16…

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 140737488355472
KERN_INVALID_ADDRESS at 0x800000000090.
Crashed thread (`com.facebook.react.runtime.JavaScript`, thread 10 of 21):
at _pthread_start
at NSThread__start
at +[RCTJSThreadManager runRunLoop]
at _CFRunLoopRunSpecificWithOptions
at __CFRunLoopRun
at __CFRunLoopDoBlocks
at CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK
at facebook::react::RCTMessageThread::runAsync
at facebook::react::RCTMessageThread::tryFunc
at facebook::react::tryAndReturnError
at std::__1::__function::__func<T>::operator()
at facebook::react::RuntimeScheduler_Modern::runEventLoop
at facebook::react::RuntimeScheduler_Modern::runEventLoopTick
at facebook::react::RuntimeScheduler_Modern::performMicrotaskCheckpoint
at facebook::hermes::(anonymous namespace)::HermesRuntimeImpl::drainMicrotasks
at hermes::vm::Runtime::drainJobs
at hermes::vm::Callable::executeCall0
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::NativeFunction::_nativeCall
at hermes::vm::arrayPrototypeMap
at hermes::vm::Callable::executeCall3
at hermes::vm::JSFunction::_callImpl
at hermes::vm::Runtime::interpretFunctionImpl
at hermes::vm::Interpreter::interpretFunction<T>
at hermes::vm::Interpreter::handleCallSlowPath
at hermes::vm::Runtime::raiseTypeErrorForCallable
at hermes::vm::Runtime::raiseTypeErrorForValue
at hermes::vm::Runtime::raiseTypeErrorForValue
at hermes::vm::raisePlaceholder
at hermes::vm::raisePlaceholder
at hermes::vm::JSError::setMessage
at hermes::vm::JSObject::defineOwnPropertyInternal
at hermes::vm::JSProxy::defineOwnProperty

Device/OS: iPhone18,1, iOS 26.6.2 (build 23G90), 12.29GB device, 114MB free (0.9%). App: 1.4.8+631.

All ten: React Native 0.81.5, hermes-engine pod 0.81.5, New Architecture / Fabriled: no/level: fatal`.

[db-flutterwave]

React Native 0.81.5 (hermes-engine pod 0.81.5, New Architecture / Fabric enabled)

@julwhitney13 quick clarification,0.81.5 is your RN version, right? I ask because on our end (RN 0.83.10 - which we just downgraded to from RN 0.86.2) the actual hermes-engine pod resolves to a completely different version string than the RN release number - 0.14.1 for classic Hermes, or a date-based build tag like 250829098.x for Hermes V1. Could you check your Podfile.lock for the exact line under hermes-engine (...) and paste it? Want to confirm you're not just restating the RN version in your last comment.

Also, is Hermes V1 enabled for you, or is it running classic Hermes? From what I can tell, V1 was only available as an experimental opt-in starting at RN 0.83 and became default at 0.84, so at 0.81.5 it seems like V1 shouldn't even be selectable unless you're doing something custom (e.g. RCT_HERMES_V1_ENABLED). Want to confirm since your crash signatures look different from the original HadesGC ones in my report, and I want to make sure we're not conflating two separate bugs.

We're currently trying to downgrade to a version of React Native that doesn't experience this crash and 0.83.10 seems to use classic hermes which had no issue in our previous RN version before we upgraded and don't want to go back to that older version.