Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#1,936 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 3 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
Meio dia
Facilidade para iniciantes
55/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
android, cpp, java
Domínio
database, mobile

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
C++
Estrelas
326
Forks
137
Merge médio
2d 5h
PRs com merge (30d)
8

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de firebase/firebase-cpp-sdk

Todas as issues de firebase/firebase-cpp-sdk

Issues semelhantes

Mais issues de C++

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.