SIGABRT in EventQueue::flushEvents / RawEvent destructor on Android (New Architecture, RN 0.86.2) during heavy JS-thread work
还没有人认领这个 Issue。
- 主要语言
- C++
- 星标
- 127k
- 派生
- 25.3k
- 平均合并
- 1 天 23 小时
- 30 天内合并 PR
- 4
描述
Body
Description
We're seeing a native SIGABRT crash (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
- React Native: 0.86.2
- Expo SDK: 57
- Architecture: New Architecture (Fabric) — mandatory on this RN version
- Hermes: yes
- Platform: Android 16
- Device: Samsung Galaxy S24 FE (SM-S721B), arm64-v8a
- App version tag: 1.4.3 (build 40)
Repro context
Both occurrences happened during the same user flow:
- App resumes from background (
onResume). - User taps a sync/refresh action, which kicks off a data import: a network download followed by a single large SQLite transaction (
expo-sqlite,withExclusiveTransactionAsync) that sequentially imports ~19 groups of records, each step logged synchronously viaconsole.log. - A few milliseconds after one of the intermediate import steps logs, the process aborts.
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
SIGABRT: Abort
at <unknown> (<unknown>)
at facebook::jni::detail::FunctionWrapper<T>::call (Registration-inl.h:95)
at facebook::jni::detail::CallWithJniConversions<T>::call (Registration-inl.h:66)
at facebook::jni::detail::MethodWrapper<T>::dispatch (Registration-inl.h:129)
at facebook::jni::JNativeRunnable::run (NativeRunnable.h:44)
at std::__ndk1::function<T>::operator() (function.h:978)
at std::__ndk1::__function::__value_func<T>::operator()[abi:ne180000] (function.h:425)
at std::__ndk1::__function::__func<T>::operator() (function.h:308)
at std::__ndk1::__function::__alloc_func<T>::operator()[abi:ne180000] (function.h:166)
at std::__ndk1::__invoke_void_return_wrapper<T>::__call[abi:ne180000]<T> (invoke.h:419)
at std::__ndk1::__invoke[abi:ne180000]<T> (invoke.h:344)
at facebook::react::(anonymous namespace)::wrapRunnable::lambda::operator() (JMessageQueueThread.cpp:37)
at std::__ndk1::function<T>::operator() (function.h:978)
at std::__ndk1::__function::__value_func<T>::operator()[abi:ne180000] (function.h:425)
at std::__ndk1::__function::__func<T>::operator() (function.h:308)
at std::__ndk1::__function::__alloc_func<T>::operator()[abi:ne180000] (function.h:166)
at std::__ndk1::__invoke_void_return_wrapper<T>::__call[abi:ne180000]<T> (invoke.h:419)
at std::__ndk1::__invoke[abi:ne180000]<T> (invoke.h:344)
at const::lambda::operator() (ReactInstance.cpp:93)
at std::__ndk1::function<T>::operator() (function.h:978)
at std::__ndk1::__function::__value_func<T>::operator()[abi:ne180000] (function.h:425)
at facebook::react::RuntimeScheduler_Modern::runEventLoop (RuntimeScheduler_Modern.cpp:266)
at facebook::react::RuntimeScheduler_Modern::runEventLoopTick (RuntimeScheduler_Modern.cpp:312)
at facebook::react::RuntimeScheduler_Modern::executeTask (RuntimeScheduler_Modern.cpp:375)
at facebook::react::Task::execute (Task.cpp:60)
at std::__ndk1::function<T>::operator() (function.h:978)
at std::__ndk1::__function::__value_func<T>::operator()[abi:ne180000] (function.h:425)
at std::__ndk1::__function::__func<T>::operator() (function.h:308)
at std::__ndk1::__function::__alloc_func<T>::operator()[abi:ne180000] (function.h:166)
at std::__ndk1::__invoke_void_return_wrapper<T>::__call[abi:ne180000]<T> (invoke.h:419)
at std::__ndk1::__invoke[abi:ne180000]<T> (invoke.h:344)
at const::lambda::operator() (EventBeat.cpp:70)
at std::__ndk1::function<T>::operator() (function.h:978)
at std::__ndk1::__function::__value_func<T>::operator()[abi:ne180000] (function.h:425)
at facebook::react::EventQueue::flushEvents (EventQueue.cpp:113)
at std::__ndk1::vector<T>::~vector[abi:ne180000] (vector:501)
at std::__ndk1::vector<T>::__destroy_vector::operator()[abi:ne180000] (vector:490)
at std::__ndk1::vector<T>::__clear[abi:ne180000] (vector:920)
at std::__ndk1::vector<T>::__base_destruct_at_end[abi:ne180000] (vector:926)
at std::__ndk1::allocator_traits<T>::destroy[abi:ne180000]<T> (allocator_traits.h:316)
at std::__ndk1::__destroy_at<facebook::react::RawEvent> (construct_at.h:67)
at facebook::react::RawEvent::~RawEvent (RawEvent.h:25)
at std::__ndk1::shared_ptr<T>::~shared_ptr[abi:ne180000] (shared_ptr.h:645)
at std::__ndk1::__shared_weak_count::__release_shared[abi:ne180000] (shared_ptr.h:184)
at <unknown> (<unknown>)
at <unknown> (<unknown>)
at <unknown> (<unknown>)
at <unknown> (<unknown>)
at <unknown> (<unknown>)
at abort (<unknown>)
Notes
- Low frequency so far (2 occurrences on 1 device over 4 days), but 100% of the stack is React Native internals — no app frame to act on from our side.
- Happy to share more Sentry context (breadcrumbs, device info) if useful.
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 EventQueue.cpp:113 和 RawEvent.h:25 开始,然后通过 EventBeat.cpp、RuntimeScheduler_Modern.cpp、JMessageQueueThread.cpp 和 ReactInstance.cpp 跟踪周边的调度流程。尽可能复现 Android foreground-and-import 场景,并确定事件交付中止的原因;当失败原因已确定,并且有经过验证的修复或回归测试时,即视为完成。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- android, cpp, react-native, sqlite
- 领域
- mobile
- Issue 类型
- 缺陷
- 难度
- 5/5
- 预计耗时
- 一周以上
- 活跃度
- 冷清
- 描述清晰度
- 需要澄清
- 新手友好度
- 35/100