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

[Database][Android] SIGSEGV in Database::DeleteInternal when embedded bridge-class init fails; FindClassInFiles passes JNI-form names to loadClass on Android

Offen
  • Stimmt etwas nicht?
#1,936 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 3 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
Ein halber Tag
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
android, cpp, java
Bereich
database, mobile

Rechercherichtung

Start with FindClassInFiles in app/src/util_android.cc, where the Android branch passes the JNI-form name to loadClass without the slash-to-dot replacement the desktop branch does. The second part is Database::GetInstance and Database::DeleteInternal, where a null App* is dereferenced on init failure; the reporter's tombstone points there. Done when the Android branch converts separators like the desktop branch, and a failed init returns an error instead of crashing. Check the existing tests for both paths before changing them.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

[Database][Android] SIGSEGV in Database::DeleteInternal when embedded bridge-class init fails; FindClassInFiles passes JNI-form names to loadClass on Android

SDK: Firebase C++ SDK 13.12.0, Realtime Database (libFirebaseCppApp-13_12_0.so), arm64 Android.

Two related defects, one crash. Reporting both together because the second turns the first from "error return" into "process death".

1. Init failure crashes instead of returning an error (the SIGSEGV)

When Database::GetInstance cannot finish DatabaseInternal init (in our case: embedded Java bridge classes fail to resolve, see §2), the code path ends in delete database → Database::DeleteInternal, which dereferences a null App* (MakeKey(app=null) → app->name()).

Tombstone (deterministic, every run once the init fails):

signal 11 (SIGSEGV), SEGV_MAPERR, fault addr 0x8 (null+8 read)
#00 libFirebaseCppApp-13_12_0.so  firebase::database::Database::DeleteInternal()+192
#01 libFirebaseCppApp-13_12_0.so  firebase::database::Database::GetInstance(...)+792
#02 libFirebaseCppApp-13_12_0.so  Firebase_Database_CSharp_InternalFirebaseDatabase_GetInstanceInternal

Expected: init failure returns an error / null instance. Actual: SIGSEGV. This half is environment-independent — any init failure ends in a crash rather than a diagnosable error, which is also what made §2 so hard to root-cause (no error, just death).

2. Android branch of FindClassInFiles skips the slash→dot conversion the desktop branch does

app/src/util_android.cc, FindClassInFiles (verified on current main):

  • Desktop branch converts before calling loadClass: 
    std::string class_name_str(class_name);
std::replace(class_name_str.begin(), class_name_str.end(), kPathSeparator, '.');
    with LogDebug("Load class %s (a.k.a. %s)", ...).
  • Android branch passes the raw JNI-form name straight into DexClassLoader.loadClass: 
    LogDebug("Load class %s", class_name);
jstring class_name_object = env->NewStringUTF(class_name);
... kLoadClass ...

ClassLoader.loadClass takes binary names (dotted). On typical standalone apps ART tolerates the slashed form so nobody notices; under a custom class-loader setup the lookup fails. Preceding log line in our runs:

E firebase: Java class com/google/firebase/database/internal/cpp/CppTransactionHandler not found.

Suggested fix: the same 3-line std::replace in the Android branch — makes both branches consistent, zero behavior change where lookup already succeeds.

Environment (disclosed so this isn't mis-triaged)

The game runs hosted in another app's process (launcher creates the game context via createPackageContext and hosts its activity). That is why the class-loader topology differs from standalone and why §2 bites here first. But §1 needs no hosted setup to matter: any GetInstance init failure on any app crashes today. And §2 is a contract violation that only happens to work standalone.

Happy to attach the full tombstone + logcat and to test a patched build. Thanks for the SDK.

Vorherrschende Sprache
C++
Sterne
326
Forks
137
Ø Merge
2 T. 5 Std.
Gemergte PRs (30 T.)
8

Entwicklungsumgebung

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 firebase/firebase-cpp-sdk

Alle Issues in firebase/firebase-cpp-sdk

Ähnliche Issues

Weitere Issues zu C++

Neue Issues direkt in Ihr Postfach

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