Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,936 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 3 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
Une demi-journée
Accessibilité débutants
55/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
android, cpp, java
Domaine
database, mobile

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

[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.

Langage dominant
C++
Étoiles
326
Forks
137
Merge moyen
2 j 5 h
PR mergées (30 j)
8

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de firebase/firebase-cpp-sdk

Toutes les issues de firebase/firebase-cpp-sdk

Issues similaires

Plus d'issues C++

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.