IssueTracker

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

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

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

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.

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)

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!

Thank you, I'll try it and check.

Hello. I have similar experience.

• I'm using mlkit-language 16.1.1
• I didnot meet this error until using AGP 4.2
• I can get this error since using AGP 7.0
• This error raised on Release build only(minimized by R8)
• This error raised without obfuscation.

Also I found there is a post which presents same issue on stackoverflow.

https://stackoverflow.com/questions/68832304/mlkit-translate-sdk-crashes-in-release-build

I created reproducible project.

$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp7 mlkit_agp7
$ cd mlkit_agp7
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity

$ adb logcat -b crash -d
10-19 19:41:49.844 17810 17810 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf9d733c in tid 17810 (e.myapplication), pid 17810 (e.myapplication)
10-19 19:41:50.473 17849 17849 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-19 19:41:50.473 17849 17849 F DEBUG   : Build fingerprint: 'google/crosshatch/crosshatch:12/SPB5.210812.002/7671067:user/release-keys'
10-19 19:41:50.473 17849 17849 F DEBUG   : Revision: 'MP1.0'
10-19 19:41:50.473 17849 17849 F DEBUG   : ABI: 'arm64'
10-19 19:41:50.473 17849 17849 F DEBUG   : Timestamp: 2021-10-19 19:41:49.903736988+0900
10-19 19:41:50.473 17849 17849 F DEBUG   : Process uptime: 0s
10-19 19:41:50.473 17849 17849 F DEBUG   : Cmdline: com.example.myapplication
10-19 19:41:50.474 17849 17849 F DEBUG   : pid: 17810, tid: 17810, name: e.myapplication  >>> com.example.myapplication <<<
10-19 19:41:50.474 17849 17849 F DEBUG   : uid: 10240
10-19 19:41:50.474 17849 17849 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf9d733c
10-19 19:41:50.474 17849 17849 F DEBUG   :     x0  0000000000000000  x1  00000000000008fc  x2  0000007a76760c71  x3  0000000000000000
10-19 19:41:50.474 17849 17849 F DEBUG   :     x4  0000000000000010  x5  0000007ba4db49d0  x6  0000007b34dc3680  x7  3de38e3900000608
10-19 19:41:50.474 17849 17849 F DEBUG   :     x8  0000007bb4dbedf0  x9  0000007acf9db2aa  x10 0000000000000000  x11 0000007acf9d6640
10-19 19:41:50.474 17849 17849 F DEBUG   :     x12 0000000000000009  x13 0000000000000000  x14 0000000000000061  x15 00000000ebad6a89
10-19 19:41:50.474 17849 17849 F DEBUG   :     x16 0000007a767cfef8  x17 0000007d9a564b40  x18 0000007da3830000  x19 0000007feaf56a08
10-19 19:41:50.474 17849 17849 F DEBUG   :     x20 0000000000000000  x21 0000007ba4da50b0  x22 0000007bb4dbedf0  x23 0000007ba4da50b8
10-19 19:41:50.474 17849 17849 F DEBUG   :     x24 0000000000000009  x25 000000000000067e  x26 0000000000000012  x27 0000000000000008
10-19 19:41:50.474 17849 17849 F DEBUG   :     x28 0000007b64dc8440  x29 0000000000000000
10-19 19:41:50.474 17849 17849 F DEBUG   :     lr  0000007a7678a964  sp  0000007feaf56810  pc  0000007a7678b7c0  pst 0000000060000000
10-19 19:41:50.474 17849 17849 F DEBUG   : backtrace:
10-19 19:41:50.474 17849 17849 F DEBUG   :       #00 pc 000000000003c7c0  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #01 pc 000000000003b960  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #02 pc 000000000003bb48  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #03 pc 000000000003bafc  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #04 pc 0000000000036c98  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #05 pc 00000000000324a4  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #06 pc 0000000000031b5c  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (Java_com_google_mlkit_nl_languageid_internal_LanguageIdentificationJni_nativeIdentifyLanguage+100) (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)

But after downgrade to AGP 4.2, crash is not reproducible.

$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp42 mlkit_agp42
$ cd mlkit_agp42
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity

Also, I tried to disable inline optimizers on R8 with AGP 7.0, and crash is not reproducible.

$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp7_r8_disable_inline_optimizer  mlkit_agp7_r8
$ cd mlkit_agp7_r8
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity

I tried the repro steps but got a NPE when I run ./gradlew :app:pPRUA

FAILURE: Build failed with an exception.

* What went wrong:
java.lang.NullPointerException
> java.lang.NullPointerException (no error message)

Could you also check if this is reproducible on 17.0.0 or 17.0.1? If yes, could you attach the full log that I can take a look? Thanks!

Here are gradle build scan logs for each branches.
All builds were clean build, and disabled build cache.

• mlkit_agp7 : https://scans.gradle.com/s/qrymdqfzwokbq
• mlkit_agp42 : https://scans.gradle.com/s/b6644hzfyfhaw
• mlkit_agp7_r8_disable_inline_optimizer : https://scans.gradle.com/s/c6h5hy2nxod4u
  • You can see R8 debug mode on build log : https://scans.gradle.com/s/c6h5hy2nxod4u/console-log#L95

Also, I pushed to update MLKit Language Id version 17.0.1 on mlkit17_agp7 branch And here is gradle build scan

• https://scans.gradle.com/s/ytaa2kkbp5vc4
  • Here is version of com.google.mlkit:language-id

And here is crash log after apply 17.0.1
You can see that BuildId of liblanguage_id_l2c_jni.so was changed from 859ec0ec2000a39e6ae8ed42e1704f46 to be6e59455cc10135330c93acdebfc121

10-20 03:07:24.522 24587 24628 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf995426 in tid 24628 (pool-3-thread-3), pid 24587 (e.myapplication)
10-20 03:07:25.190 24710 24710 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-20 03:07:25.190 24710 24710 F DEBUG   : Build fingerprint: 'google/crosshatch/crosshatch:12/SPB5.210812.002/7671067:user/release-keys'
10-20 03:07:25.190 24710 24710 F DEBUG   : Revision: 'MP1.0'
10-20 03:07:25.190 24710 24710 F DEBUG   : ABI: 'arm64'
10-20 03:07:25.190 24710 24710 F DEBUG   : Timestamp: 2021-10-20 03:07:24.583346246+0900
10-20 03:07:25.190 24710 24710 F DEBUG   : Process uptime: 0s
10-20 03:07:25.190 24710 24710 F DEBUG   : Cmdline: com.example.myapplication
10-20 03:07:25.190 24710 24710 F DEBUG   : pid: 24587, tid: 24628, name: pool-3-thread-3  >>> com.example.myapplication <<<
10-20 03:07:25.190 24710 24710 F DEBUG   : uid: 10240
10-20 03:07:25.190 24710 24710 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf995426
10-20 03:07:25.190 24710 24710 F DEBUG   :     x0  0000007b54da9d30  x1  0000007d9a5fe7cc  x2  0000000000000000  x3  0000000000000010
10-20 03:07:25.190 24710 24710 F DEBUG   :     x4  0000000000000000  x5  0000007c34dbc79c  x6  0000002f0000083b  x7  000003c300002dd5
10-20 03:07:25.190 24710 24710 F DEBUG   :     x8  0000000000000001  x9  0000000000000004  x10 0000000000000010  x11 0000000000000000
10-20 03:07:25.190 24710 24710 F DEBUG   :     x12 0000000000000000  x13 000000000000217e  x14 0000007acf9932a8  x15 000000000000217e
10-20 03:07:25.190 24710 24710 F DEBUG   :     x16 0000000000000000  x17 0000007d9a564c78  x18 0000007a6ef18000  x19 0000007c34dbc580
10-20 03:07:25.190 24710 24710 F DEBUG   :     x20 0000007ca4dc7170  x21 0000007ca4dc7800  x22 0000007ca4dc71e0  x23 0000000000000000
10-20 03:07:25.190 24710 24710 F DEBUG   :     x24 0000000000000018  x25 0000000000000007  x26 0000000000000006  x27 0000000000000004
10-20 03:07:25.190 24710 24710 F DEBUG   :     x28 0000007ca4dc7090  x29 0000007cb4da9940
10-20 03:07:25.190 24710 24710 F DEBUG   :     lr  0000007a770a9624  sp  0000007a6f7de9c0  pc  0000007a770a96a8  pst 0000000020000000
10-20 03:07:25.190 24710 24710 F DEBUG   : backtrace:
10-20 03:07:25.190 24710 24710 F DEBUG   :       #00 pc 00000000000386a8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #01 pc 00000000000388a0  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #02 pc 00000000000844a0  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #03 pc 000000000008783c  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #04 pc 0000000000035fc4  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #05 pc 0000000000034954  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #06 pc 00000000000340e8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (Java_com_google_mlkit_nl_languageid_internal_ThickLanguageIdentifier_nativeIdentifyPossibleLanguages+108) (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #07 pc 00000000002d9a44  /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #08 pc 000000000020a700  /apex/com.android.art/lib64/libart.so (nterp_helper+5648) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #09 pc 00000000000cd0dc  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #10 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #11 pc 00000000000ccfa8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #12 pc 0000000000557cb4  /system/framework/arm64/boot-framework.oat (android.os.Binder.transact+148) (BuildId: 43a571a0ad85d6451b47016336a541ecb0eb12bb)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #13 pc 000000000020b53c  /apex/com.android.art/lib64/libart.so (nterp_helper+9292) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #14 pc 00000000000b7aba  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #15 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #16 pc 00000000000a7496  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #17 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #18 pc 00000000000a7360  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #19 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #20 pc 000000000009e46c  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #21 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #22 pc 00000000000d33d6  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #23 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #24 pc 000000000009df0a  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #25 pc 0000000000209124  /apex/com.android.art/lib64/libart.so (nterp_helper+52) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #26 pc 000000000009e350  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #27 pc 000000000037b9ac  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+988) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #28 pc 00000000003751d4  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+68) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #29 pc 000000000020aec4  /apex/com.android.art/lib64/libart.so (nterp_helper+7636) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #30 pc 000000000009e370  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #31 pc 00000000001bf35c  /apex/com.android.art/javalib/arm64/boot.oat (java.lang.Thread.run+76) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #32 pc 00000000002d0164  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #33 pc 000000000031ccac  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+156) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #34 pc 00000000003cf8a0  /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, jvalue const*)+380) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #35 pc 0000000000460894  /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+992) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #36 pc 00000000000b1910  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264) (BuildId: ba489d4985c0cf173209da67405662f9)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #37 pc 00000000000513f0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: ba489d4985c0cf173209da67405662f9)

Cross-posted on R8 issue tracker. https://issuetracker.google.com/issues/203573699

Hi,

Looks like we figured out the root cause in b/203573699

For temporary workarounds for the existing SDKs, you need to add this rule

-keep class com.google.mlkit.nl.languageid.internal.LanguageIdentificationJni { *; }

for language-id 16.1.1, and add this rule

-keep class com.google.mlkit.nl.languageid.internal.ThickLanguageIdentifier { *; }

for version language-id 17.0.0+ for the newer model.

We'll fix this issue in the upcoming release so that you'll not need these workarounds in the future release.

Thanks a lot for reporting this issue!

Added workarounds in Known issues section in public docs.

1 & 6 - WorkManager workers and broadcast receiver interacting with the same Room database is fine. I was more curious on the operations being done, but it does seem to be write operations in transactions.

4 - You can configure the timeout in Room's onOpen callback, and these can be installed in the builder via addCallback(). In the onOpen just do: conenction.execSQL("PRAGMA busy_timeout = <time in ms>")

7 - You should check your AndroidManifest.xml, WorkManager could run in another process, but only if configured to do so, check if your app has multiple processes by checking the manifest and looking for android:process=

8 - Because AndroidSQLiteDriver is an Android only API you need to create an actual / expect function that return a SQLiteDriver along with the necessary Kotlin multiplatform source set configuration so that for Android it'll return AndroidSQLiteDriver while for other platforms I'll return BundledSQLiteDriver and you pipe that to `setDriver().

Hi. I have updated my app replaced BundledSQLiteDriver with AndroidSQLiteDriver as you suggested.

For now I don't see SQLException: Error code: 5, message: database is locked anymore but I see the new error java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction.

Here is the stack trace.

Fatal Exception: java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction.
       at android.database.sqlite.SQLiteSession.throwIfNoTransaction(SQLiteSession.java:917)
       at android.database.sqlite.SQLiteSession.endTransaction(SQLiteSession.java:400)
       at android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:588)
       at androidx.room.coroutines.AndroidSQLiteDriverPooledConnection.transaction(AndroidSQLiteDriverConnectionPool.android.kt:94)
       at androidx.room.coroutines.AndroidSQLiteDriverPooledConnection.access$transaction(AndroidSQLiteDriverPooledConnection.java:53)
       at androidx.room.coroutines.AndroidSQLiteDriverPooledConnection$transaction$1.invokeSuspend(AndroidSQLiteDriverConnectionPool.android.kt:12)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:98)
       at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.java:113)
       at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
       at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:586)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:820)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:717)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:704)
        

Hi. Happy New Year!

After week with AndroidSQLiteDriver I see no SQLException: Error code: 5, message: database is locked but see java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction..

So I think your theory may be right that this is something with "Coroutines and RoomDB".

Hi. This is still a problem. Should I create new issue about java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction. or it is going to be fixed in scope of this issue?

This issue is still blocker for my app and there is already 46 days passed since I reported it.

Hi - Sorry for the delayed response.

I think you are indeed hitting a different issue with the AndroidSQLiteDriver, specifically around the Android version of the connection pool. I can work on this soon.

But I am worried that we still have not found the root cause of your original issue with the BundledSQLiteDriver and the database is locked, if you could somehow create a sample app (I know it can be hard) that would help us a lot.

I also want to mention a 3rd option for Android and that is not using a SQLiteDriver with Room which in turn will cause it to default to using SupportSQLite the underlying SQLite APIs before Room was converted to KMP.

Hi. Thank you for your response. For now I am not succeed in reproduce the issue with the BundledSQLiteDriver and the database is locked. But I will try more.

Speaking of "not using a SQLiteDriver" - am I understood right that I just need to delete .setDriver() method?

Thats right, not calling setDriver will make Room work in compatibility mode and will use the FrameworkSQLiteOpenHelper and its APIs and will keep the 'before KMP coroutines' behavior.

So. I removed setDriver method. The builder is still in common module. Now the error IllegalStateException: Cannot perform this operation because there is no current transaction happens every time when app trying to make database operation using this code

private val dbMutex = Mutex()

suspend fun <R> MyDatabse.workaroundWithTransaction(block: suspend TransactionScope<R>.() -> R) {
    dbMutex.withLock {
        useWriterConnection {
            it.deferredTransaction(block)
        }

        // TODO: Fix https://issuetracker.google.com/issues/340606803#comment2
        // Manually triggers invalidation
        invalidationTracker.refreshAsync()
    }
}

The stack trace:

java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction.
	at android.database.sqlite.SQLiteSession.throwIfNoTransaction(SQLiteSession.java:1021)
	at android.database.sqlite.SQLiteSession.endTransaction(SQLiteSession.java:419)
	at android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:833)
	at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.endTransaction(FrameworkSQLiteDatabase.android.kt:100)
	at androidx.room.driver.SupportSQLitePooledConnection.transaction(SupportSQLiteConnectionPool.android.kt:90)
	at androidx.room.driver.SupportSQLitePooledConnection.access$transaction(SupportSQLiteConnectionPool.android.kt:51)
	at androidx.room.driver.SupportSQLitePooledConnection$transaction$1.invokeSuspend(Unknown Source:15)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:98)
	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:113)
	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:586)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:820)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:717)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:704)

Note: there was AndroidSQLiteDriverPooledConnection now it is SupportSQLitePooledConnection in stack trace.

Also, users report that when using the Android driver, sometimes the database does not return a response from an SQL query where it should have returned it.

The example of such request

@Query("""SELECT * from "${Holder.TABLE_HOLDER}" WHERE "${Holder.COLUMN_HOLDER_ID}" LIKE :holderId""")
fun getHolderById(holderId: String): Flow<Holder?>

I found the way to reproduce it!

First you launch workaroundWithTransaction method, then getHolderById method. The result: getHolderById stops returning result.

This error is ever worse than before because it is reproduceable in almost 100% cases!

I have to return to BundledSQLiteDriver

Can you provide more details on the repro case? Is it possible to create a sample repro? Or maybe a test? Can you please show us some code?

Are you starting a transaction and in the transaction you are also collecting the Flow?

db.workaroundWithTransaction {
  db.dao.getHolderById(...).collect {
    
  }
}

This is not a valid usage of Flow because you are essentially starting a transaction that will never end and that might explain the database locked exception you are seeing.

Here another test I have created based on your description but it works fine for me on all drivers:

@Test
fun check() = runTest {
    async(Dispatchers.IO) {
        // Insert 100 items in a deferred transaction and notifying invalidation tracker
        repeat(100) { id ->
            db.useWriterConnection {
                it.deferredTransaction {
                    db.dao().insert(SampleEntity(id.toLong()))
                }
            }
            db.invalidationTracker.refreshAsync()
        }
    }

    async(Dispatchers.IO) {
        // Collect list of inserted items until list is of size 100, meaning
        // all 100 items where inserted and a result with a list of them was received
        db.dao().getItemListFlow().collect {
            if (it.size == 100) {
                cancel()
            }
        }
    }
}

Hi. The order of reproducing:

1. call db.dao().getHolderById("some_id").first() - will return a result
2. call db.useWriterConnection {...} - to make any change in db
3. call db.dao().getHolderById("some_id").first() - no longer returns a result

Only restarting the app will make db.dao().getHolderById("some_id").first() work again.

For now I can't create a simple repo, maybe later.

I don't have a minimal repro case, but I am facing this issue in my project (https://github.com/tasks/tasks)

I have been using AndroidSQLiteDriver in production and never had a database locked crash. Many months ago I briefly deployed BundledSQLiteDriver but reverted it because of this crash

This weekend I wanted to use window functions on Android so I switched to BundledSQLiteDriver again. It did not crash on my Pixel 9 Pro during development so I thought the issue was fixed. Then I deployed my changes and am getting tons of crashes again

I then tested on a CAT S22. This thing is a potato and I get database locked crashes easily.

I commented out my transactor.withTransaction calls so the only transactions are generated by Room and it still crashes

When I use PRAGMA busy_timeout to increase the timeout then the database just deadlocks instead of crashing

Just to add more details:

I can comment out my @RawQuery, useWriterConnection, and useReaderConnection calls, and I still get database locked crashes using only generated @Query, @Insert, @Update, and @Delete functions. The app runs in a single process

Switching from BundledSQLiteDriver back to AndroidSQLiteDriver fixes the issue completely

On my CAT S22 the app crashes on first launch after a clean install 100% of the time. The app will start after relaunching but it will then crash frequently during synchronization

Hi. Is there any updates? I believe it is should be P1 issue.

My guess, without looking at any of the library code, is that transactions are not being queued with the BundledSQLiteDriver. I have firebase crashes from 20+ different database functions at this point. My pixel 9 pro is probably servicing requests fast enough to not crash, the CAT S22 not so much.

I'll grab an old Nexus 5 I have around that is pretty potato to see if I can repro this.

Room has a connection pool manager and it has 4 reader connections and one writer, it uses coroutines to suspend callers when the connections are being used. This is indeed different than Android's driver that 'blocks' callers when a connection is not available.

I became aware of room's connection strategy when I learned that reading data with Room flows acquired a transaction, which was a surprising source of performance problems at my day job 🙃

I thought using AndroidSQLiteDriver was analogous to not specifying a driver at all, and would use the connection/transaction strategy you mentioned. Based on my observations I assumed this was related to the problem with the BundledSQLiteDriver - transactions are happening on multiple connections rather than queuing them on one connection? I'm just speculating and could also be mistaken about how this works under the hood.

If you're trying to repro by running my app but aren't having any luck let me know, I could create a branch that seeds the app with some test data or something.

I was able to successful run the Tasks app but indeed haven't had luck reproducing the issue, so if you do end up creating that branch with seed data I will gladly use it.

Reading data via a Flow returned from a @Dao has never required a transaction, unless specified in the DAO via @Transaction. Would love to hear more about the surprising performance issues.

However, I agree that transactions tend to be a source of performance issues. If no driver is used Room uses SupportSQLite and Android's SQLite bindings, transactions there always use the single primary connection and they block each other. When using the AndroidSQLiteDriver, similarly that uses Android's SQLite binding which will also uses the primary connection. There is a difference in code paths when no driver is specified and when AndroidSQLiteDriver is used, but it is in terms of backwards compatibility of other SupportSQLite APIs (see warning in https://developer.android.com/training/data-storage/room/room-kmp-migration#set_a_sqlite_driver).

Now BundledSQLiteDriver internally does not have a connection pool like the Android driver does and instead relies on Room's which we try to test as much as we can but of course it is not as mature's as Android. So we really appreciate you trying it out and reporting these issues. As for how different it is, the main difference is that the connection pool is suspending, other coroutines can continue while a connection is being used, this is very different from the other drivers that will 'block' the caller which for DAO functions Room alleviates by using a FIFO single threaded pool (the transaction executor) but can't control when other blocking APIs are used (beginTransaction). So yes, it is possible to start multiple transactions with Room's connection pool, but in essence they are also queued via suspending coroutines as the connection is being acquired and returned to the pool.

Reading data via a Flow returned from a @Dao has never required a transaction, unless specified in the DAO via @Transaction. Would love to hear more about the surprising performance issues.

The issue we were having was that on startup our sync loop would sometimes start a transaction before our UI created a Room flow, and the UI flow would be blocked until the sync transaction finished. I think we jumped to the conclusion that Room flows acquire a transaction when they're started, but I just looked at the library code again and I think its just acquiring a transaction the first time you observe a table 🤦 edit: OK I'll stop derailing this ticket, but when a flow is started and its the first observer on a table there is a transaction, and when a flow finishes and its the last observer on a table there is a transaction

I was able to successful run the Tasks app but indeed haven't had luck reproducing the issue, so if you do end up creating that branch with seed data I will gladly use it.

I will get this to you ASAP

Yes, if a Flow needs to observe tables that have no observer 'installed' then Room has to create some TRIGGERs to start observing the tables and it does it in a transaction. Unfortunately this has to block the Flow's initial query to guarantee consistency. I think we would need a different invalidation system, not TRIGGER based, to possibly avoid that start and end transaction but I don't think we have enough strong compelling reasons to change the system.

I have attached a backup file that you can import into Tasks by tapping on 'Settings > Backups > Import' and selecting the file.

On my CAT S22 with this commit that just adds BundledSQLiteDriver it crashes with a database locked error, and the previous commit does not.

The next-worst phone I have is a Galaxy S9 and I cannot get the database locked error on there, even with 10x as much data in the database

When I look at Firebase, these are the types of phones experiencing this crash: TP-Link Neffos A5 Tinno Y52 ZTE Blade A34 Moto E13 & E20 Xiamo Redmi A1 & A2 Alcatel 1C Transsion Tecno Spark Go 1 Mobiwire Smart C11

This list is not exhaustive, I just grabbed it from the first 5 distinct crashes. I've never even heard of most of these phones until just now

Thank you for participating. I am really glad to see some progress and discussion on this issue.

Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <danysantiago@google.com>
Link:      https://android-review.googlesource.com/3462864

Reduce no-op transaction while syncing triggers

Reduce no-op transaction while syncing triggers 
 
The ObservedTableStates instance will return a list of observe operations (add or remove triggers) to perform if it 'needs sync'. A sync is required if at least a trigger needs to be added or removed from a table since the last sync. However, it might be that multiple observers are added and removed such that the end result of operations is actually to do nothing. In this case Room still tries to start a database transaction to not add or remove any triggers. Since transactions have lock implications it is best to avoid the transaction that if all observer operations are no-op. 
 
Example case this change is optimizing: 
1.  Flow A in UI begins collecting, trigger A is installed 
2.  UI is rotated, not using collectAsStateWithLifecycle() or equivalent 
2.a Flow A stops collecting, a sync is required 
2.b Flow A starts collecting, a sync is still required 
3.  Triggers are synced, operation on table A is no-op 
 
Bug: 380088809 
Test: Existing 
Change-Id: Iae612a1c4f8b8f1e8e15d2f60eb9bf68241570ef

Are you were able to reproduce the issue and fix it or it is an other issue got fixed?

I've spent an hour trying to repro the deadlock I mentioned in https://issuetracker.google.com/u/1/issues/380088809#comment30 when using PRAGMA busy_timeout = <time in ms> with the CAT S22. I have not been successful, so maybe that does fix my problem. I'm going to try releasing with BundledSQLiteDriver again 🤞

Hi. Are there any updates on this?

Hey - 2.7.0-alpha13 has a change that should reduce the issue, but not guaranteed.

But I was not able to reproduce the issue with the project and data from comment#39. 🙁

Things got busy so I have to dedicate more time to this issue, but its sort of a wild goose chase without a reliable repro.

Starting with the latest version, 2.7.0-alpha13, we switched to BundledSQLiteDriver, which produces hundreds of database-locked exceptions.

   Non-fatal Exception: android.database.SQLException: Error code: 5, message: database is locked
       at androidx.sqlite.driver.bundled.BundledSQLiteStatementKt.nativeStep(BundledSQLiteStatement.jvmAndroid.kt)
       at androidx.sqlite.driver.bundled.BundledSQLiteStatementKt.access$nativeStep(BundledSQLiteStatement.jvmAndroid.kt)
       at androidx.sqlite.driver.bundled.BundledSQLiteStatement.step(BundledSQLiteStatement.jvmAndroid.kt:100)
       at app.resubs.core.database.dao.PendingNotificationDao_Impl.getAll$lambda$1(PendingNotificationDao_Impl.kt:94)
       at androidx.room.util.DBUtil__DBUtil_androidKt$performSuspending$lambda$1$$inlined$internalPerform$1.invokeSuspend(DBUtil.kt:68)
       at androidx.room.util.DBUtil__DBUtil_androidKt$performSuspending$lambda$1$$inlined$internalPerform$1.invoke(DBUtil.kt:8)
       at androidx.room.util.DBUtil__DBUtil_androidKt$performSuspending$lambda$1$$inlined$internalPerform$1.invoke(DBUtil.kt:4)
       at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invokeSuspend(ConnectionPoolImpl.kt:144)
       at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invoke(ConnectionPoolImpl.kt:8)
       at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invoke(ConnectionPoolImpl.kt:4)
       at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:43)
       at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:166)
       at kotlinx.coroutines.BuildersKt.withContext(Builders.kt)
       at androidx.room.coroutines.ConnectionPoolImpl.useConnection(ConnectionPoolImpl.kt:144)
       at androidx.room.coroutines.ConnectionPoolImpl$useConnection$1.invokeSuspend(ConnectionPoolImpl.kt:13)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.internal.ScopeCoroutine.afterResume(Scopes.kt:35)

Hi ck...@gmail.com. If you have any ideas on how to reproduce the error, please help with this.

I did found that we were not configuring the busy_timeout in the initial connection which can lead to SQLITE_BUSY (error code 5). I've sent a cl to fix that.

I have another alternative / workaround for those with this issue which will also hint me to the root of the cause. In comment#10 I mentioned how increasing the timeout can help, but I realize my suggestion there was not great because it should be done on all connections and not just on the initial connection, to do this you will need to wrap your driver, here is an example code:

val actualDriver = BundledSQLiteDriver()
val driverWrapper =
  object : SQLiteDriver by actualDriver {
    override fun open(fileName: String): SQLiteConnection {
      return actualDriver.open(fileName).also { newConnection ->
        newConnection.execSQL("PRAGMA busy_timeout = $customBusyTimeout")
      }
    }
  }
roomDatabaseBuilder
  .setDriver(driverWrapper)

Let me know if this helps or not.

Hi ck...@gmail.com, ba...@gmail.com. Could you please test this solution on your side?

Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <danysantiago@google.com>
Link:      https://android-review.googlesource.com/3486790

Apply busy_timeout config for initial connection

Apply busy_timeout config for initial connection 
 
Fix an issue where busy_timeout was not being configured in the initial connection where schema validation is also done. The busy_timeout must be set on all connections to avoid SQLITE_BUSY. 
 
Bug: 380088809 
Test: BaseBuilderTest#setCustomBusyTimeout 
Change-Id: I9320856f64363b05bcf6407eed0efe36ef3312a3

Hi. I have applied this fix to my app and release for 10% of users. I got 4000 installs and for now I don't see this error. I am going to try with version 2.7.0-rc01.

I'm still seeing this or a similar issue on 2.7.0-rc01. I haven't tried using AndroidSQLiteDriver or any of the other workarounds listed here. Previously, I was using setQueryCoroutineContext(Dispatchers.IO.limitedParallelism(1)) which did solve the problem. I removed that after upgrading to 2.7.0-rc01.

I got this crash yesterday:

android.database.SQLException: Error code: 5, message: database is locked
    at androidx.sqlite.driver.bundled.BundledSQLiteStatementKt.nativeStep(SourceFile)
    at androidx.sqlite.driver.bundled.BundledSQLiteStatementKt.access$nativeStep(BundledSQLiteStatement.jvmAndroid.kt:0)
    at androidx.sqlite.driver.bundled.BundledSQLiteStatement.step(BundledSQLiteStatement.jvmAndroid.kt:0)
    at androidx.sqlite.driver.bundled.BundledSQLiteStatement.step(BundledSQLiteStatement.jvmAndroid.kt:100)
    at androidx.sqlite.SQLite.execSQL(com.google.android.gms:play-services-mlkit-barcode-scanning@@18.3.1:56)
    at androidx.room.coroutines.PooledConnectionImpl.endTransaction(ConnectionPoolImpl.kt:420)
    at androidx.room.coroutines.PooledConnectionImpl.transaction(ConnectionPoolImpl.kt:388)
    at androidx.room.coroutines.PooledConnectionImpl.isRecycled(ConnectionPoolImpl.kt:0)
    at androidx.room.coroutines.PooledConnectionImpl.access$isRecycled(ConnectionPoolImpl.kt:0)
    at androidx.room.coroutines.PooledConnectionImpl.withTransaction(ConnectionPoolImpl.kt:0)
    at androidx.room.coroutines.PooledConnectionImpl.withTransaction(ConnectionPoolImpl.kt:344)
    at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsKt.getCOROUTINE_SUSPENDED
    at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3$invokeSuspend$$inlined$internalPerform$1.invokeSuspend(DBUtil.kt:0)
    at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3$invokeSuspend$$inlined$internalPerform$1.invokeSuspend(DBUtil.kt:59)
    at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3$invokeSuspend$$inlined$internalPerform$1.invoke(DBUtil.kt:0)
    at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3$invokeSuspend$$inlined$internalPerform$1.invoke(DBUtil.kt:0)
    at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsKt.getCOROUTINE_SUSPENDED
    at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invokeSuspend(ConnectionPoolImpl.kt:0)
    at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invokeSuspend(ConnectionPoolImpl.kt:144)
    at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invoke(ConnectionPoolImpl.kt:0)
    at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invoke(ConnectionPoolImpl.kt:0)
    at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(ChildStackFactory.kt:43)
    at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext
    at kotlinx.coroutines.BuildersKt.withContext(DebugStrings.kt:0)
    at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext
    at kotlinx.coroutines.BuildersKt.withContext(DebugStrings.kt:1)
    at androidx.room.coroutines.ConnectionPoolImpl.useConnection(ConnectionPoolImpl.kt:144)
    at androidx.room.RoomDatabase.useConnection$room_runtime_release(RoomDatabase.android.kt:0)
    at androidx.room.RoomConnectionManager.useConnection
    at androidx.room.RoomDatabase.useConnection$room_runtime_release(RoomDatabase.android.kt:587)
    at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsKt.getCOROUTINE_SUSPENDED
    at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3.invokeSuspend(DBUtil.android.kt:0)
    at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3.invokeSuspend(DBUtil.android.kt:243)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:0)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
    at java.lang.Thread.run(Thread.java:1012)