Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

SIGABRT in EventQueue::flushEvents / RawEvent destructor on Android (New Architecture, RN 0.86.2) during heavy JS-thread work

Offen
#57,963 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Muss geklärt werden
Aktivitätsstatus
Ruhig
Tech-Stack
android, cpp, react-native, sqlite
Bereich
mobile

Rechercherichtung

Beginne mit EventQueue.cpp:113 und RawEvent.h:25 und verfolge anschließend den umgebenden Ablauf der Ablaufplanung durch EventBeat.cpp, RuntimeScheduler_Modern.cpp, JMessageQueueThread.cpp und ReactInstance.cpp. Reproduziere nach Möglichkeit das Android-Szenario foreground-and-import und ermittle, warum die Ereigniszustellung abgebrochen wird; als erledigt gilt die Aufgabe, wenn die Fehlerursache identifiziert und ein validierter Fix oder Regressionstest vorhanden ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Needs: Attention Needs: Repro

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:

  1. App resumes from background (onResume).
  2. 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 via console.log.
  3. 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.
Vorherrschende Sprache
C++
Sterne
127k
Forks
25.3k
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus react/react-native

Alle Issues in react/react-native

Ähnliche Issues

Weitere Issues zu C++

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.