Default migration crashing due attempt to re-open an already-closed object: SQLiteDatabase [124476912]

Fixed

Bug

Status Update

No update yet.

Description

an...@gmail.com

created issue #1

Feb 15, 2019 12:17PM

Component used: androidx.room:room-runtime
Version used: 2.1.0-alpha03
Devices/Android versions reproduced on: All devices. minSdk = 21. Most devices are Samsung (~90%)

I am getting tons of crashes and I am not able to reproduce them. Please see to attached stacktrace. I am using a default migration (drop everything -> recreate everything):

@Provides
@PerApplicationScope
fun provideDatabase(application: Application): VintedDatabase {
val builder = Room.databaseBuilder(
application,
VintedDatabase::class.java,
"vinted_database.db"
)
.fallbackToDestructiveMigration()
if (Debug.isDebuggerConnected()) {
builder.allowMainThreadQueries()
}
return builder.build()
}

The application is crashing on random DAO calls in various places in the app. There is a similar issue:

https://issuetracker.google.com/issues/71014717#comment3 . However, this explanation doesn't apply to me, because I am not using migration. Please see attached generated code. The crash happens on line: _db.execSQL("DROP TABLE IF EXISTS `tracking_events`");

This generated code looks very stable. Also, everything at FrameworkSQLiteOpenHelper is synchronized, and I don't get how is possible to close DB during migration. But one thing caught my eye there:

FrameworkSQLiteDatabase getWrappedDb(SQLiteDatabase sqLiteDatabase) {
FrameworkSQLiteDatabase dbRef = mDbRef[0];
if (dbRef == null) {
dbRef = new FrameworkSQLiteDatabase(sqLiteDatabase);
mDbRef[0] = dbRef;
}
return mDbRef[0];
}

Just hypothetically, what if someone gets a DB through `FrameworkSQLiteOpenHelper.getWritableDatabase()` and closes immediate, like:

FrameworkSQLiteOpenHelper.getWritableDatabase().close()

Then DB instance will be closed and opening a new writable database gives a new SQLiteDatabase instance. But getWrappedDb returns an old one because the ref was not cleared because DB was closed directly instead of FrameworkSQLiteOpenHelper. Maybe some safety is needed here, like:

if (dbRef != null && dbRef.mDelegate != sqLiteDatabase) {
//try to close old instance anyway to avoid memory leak
dbRef.close()
dbRef = null
}

//rest code

Need to mention, DAO requests could be done on a few IO threads. Maybe Single thread environment would be better?

stacktrace.txt

2.2 KB

View

Download

generated.txt

1.4 KB

View

Download

Comments

an...@gmail.com <an...@gmail.com> #2Feb 15, 2019 01:04PM

A couple of questions:

1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?

yb...@google.com <yb...@google.com> Feb 15, 2019 07:20PM

Assigned to da...@google.com.

da...@google.com <da...@google.com> #3Feb 15, 2019 08:28PM

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

an...@gmail.com <an...@gmail.com> #4Feb 18, 2019 09:32AM

Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

da...@google.com <da...@google.com> #5Feb 19, 2019 06:17PM

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

an...@gmail.com <an...@gmail.com> #6Feb 19, 2019 09:25PM

On the contrary, there was no separate process before, when crashes started.

In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)

backtrace:
  #00  pc 000000000003c7c0  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003b960  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bb48  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bafc  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000036c98  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000032714  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000031cac  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000057438  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)

da...@google.com <da...@google.com> #7Feb 19, 2019 10:01PM

FYI, ML Kit launched a new language ID SDK in the latest release, which uses a new language ID model. https://developers.google.com/ml-kit/release-notes#august_11_2021

Could you try the new SDK version(17.0.0) to check if you can still repro this native crash? Thanks!

an...@gmail.com <an...@gmail.com> #8Feb 19, 2019 10:20PM

Thank you, I'll try it and check.

da...@google.com <da...@google.com> Mar 4, 2019 08:50PM

Marked as fixed.