Repository navigation
SIGABRT in EventQueue::flushEvents / RawEvent destructor on Android (New Architecture, RN 0.86.2) during heavy JS-thread work #57963
Description
Activity
Warning
Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:
- For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
- If your bug is UI related: a Snack
- If your bug is build/upgrade related: a project using our Reproducer Template
You can read more about about it on our website: How to report a bug.Thanks for the note. This is a rare native SIGABRT (2 occurrences on 1 device over 4 days) with a stack trace entirely inside Fabric/RuntimeScheduler internals (EventQueue::flushEvents / RawEvent destructor) — no JS/app frames involved, and it depends on a timing-sensitive condition (JS thread doing sustained synchronous work right as the app resumes from background, likely with a backlog of native touch/UI events pending delivery). I don't have a deterministic reproduction I can package into RNTesterPlayground.js or a minimal project — I'm reporting it from a production crash with full context (stack trace, device/OS/RN version, breadcrumb trail) in case it's useful for triage or matches a known issue, understanding it may not meet the reproducer bar for a full investigation.
We're seeing what looks like exactly this crash in production, and can corroborate with additional data points.
Environment: RN 0.81.5 (Expo SDK 54), New Architecture, Hermes,
react-native-reanimated4.1.1. App: fitness/coaching app, ~1,100 Android 16 MAU.Devices — exclusively Samsung on Android 16 (API 36): Galaxy S22 (SM-S901U1), S23+ (SM-S916U), S23 Ultra (dm3q), S24/S24+ (e1q/e2q/SM-S926U), S25+ (SM-S936U), across five app releases. 100% foreground, always mid-interaction — typically within ~1s of a navigation transition or bottom-sheet animation. For a few users it reproduces nearly every session; their account data was audited and ruled out.
We see two faces of the same corruption:
1. SIGABRT — Scudo invalid free during event-queue cleanup (same as this issue; Google Play Vitals, symbolicated):
Scudo ERROR: invalid chunk state when deallocating address 0x<sanitized> #00 libc.so (abort) #01 libc.so (scudo::die) #04 libc.so (scudo::reportInvalidChunkState) #05 libc.so (scudo::Allocator<...>::deallocate) #07 libreactnative.so (facebook::react::EventQueue::flushEvents(facebook::jsi::Runtime&) const) #09 libreactnative.so (facebook::react::Task::execute) #10-12 libreactnative.so (RuntimeScheduler_Modern::executeTask / runEventLoopTick / runEventLoop)2. SIGSEGV — constructing the event payload
jsi::Value(Play Vitals + Sentry, identical stacks):facebook::jsi::Value::Value ← facebook::react::UIManagerBinding::dispatchEventToJS ← facebook::react::EventQueueProcessor::flushEvents ← facebook::react::EventQueue::flushEvents ← facebook::react::Task::execute ← facebook::react::RuntimeScheduler_Modern::runEventLoopTick → runEventLoopNotes that may help triage:
- These crashes are invisible to Sentry's JS layer and only intermittently captured by its NDK signal handler — Play Vitals was the reliable source. Others hitting this may simply not see it.
- Our leading suspect is the fix in 0.87.0:
5dea3b5e6c— "Events: Fix use-after-free data race in EventEmitter.cpp".dispatchEventToJSconstructs ajsi::Valuefrom the event target's instance handle — precisely the object that commit protects with the scoped lock. A racingeventTarget_/shadowNodeFamily_mutation (unmount / emitter enable-disable) corrupting the shared_ptr would explain both signatures, including theRawEventdestructor abort here. Not yet verified on 0.87 — we're on 0.81 and the commit is absent from 0.86-stable (this issue being on 0.86.2 is consistent with that). - We've filed a cherry-pick request for
5dea3b5e6cinto 0.86-stable: [0.86] Fix use-after-free data race in EventEmitter.cpp (fatal heap-corruption crashes on Android 16) reactwg/react-native-releases#1369. - Android 16's Scudo config seems to be what turns the latent race into a reliable abort — we have zero occurrences on Android ≤15 across the same fleet.
Happy to test a patched build on affected Samsung/Android 16 devices or share fuller Vitals data.
Body
Description
We're seeing a native
SIGABRTcrash (uncaught,mechanism: signalhandler) with a stack trace entirely inside Fabric/RuntimeScheduler internals — no first-party JS frames involved. It has occurred twice on the same physical device so far.Environment
Repro context
Both occurrences happened during the same user flow:
onResume).expo-sqlite,withExclusiveTransactionAsync) that sequentially imports ~19 groups of records, each step logged synchronously viaconsole.log.The JS thread is doing sustained synchronous-ish work throughout the import (a tight loop of awaited SQLite operations, several dozen ms apart), right after the app comes back to the foreground — so there may be a backlog of native UI/touch events queued for delivery to JS at the same time.
Stack trace
Notes