Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
#1,936 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 3 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
半天
新手友好度
55/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
android, cpp, java
领域
database, mobile

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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

主要语言
C++
星标
326
派生
137
平均合并
2 天 5 小时
30 天内合并 PR
8

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

firebase/firebase-cpp-sdk 的其他 Issue

查看 firebase/firebase-cpp-sdk 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。