Status Update
No update yet.
Comments
ch...@gmail.com
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
ch...@gmail.com
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
da...@google.com
-
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.
ap...@google.com
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.
da...@google.com
ch...@gmail.com
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)
al...@gmail.com
FYI, ML Kit launched a new language ID SDK in the latest release, which uses a new language ID model.
Could you try the new SDK version(17.0.0) to check if you can still repro this native crash? Thanks!
ch...@gmail.com
Thank you, I'll try it and check.
Description
Version used: 2.2.0-alpha02
Devices/Android versions reproduced on: API 29
I'm hitting a weird issue where a Flow<T> from Room will randomly stop dispatching updates (usually after a few successful emissions). I've dug into this a bit and found this in my logs:
2019-08-10 15:29:39.928 19259-19367/app.tivi.debug E/DiscoverViewModel: Fail() during execute
java.lang.IllegalArgumentException: column '`show_id`' does not exist. Available columns: [id, request, entity_id, timestamp]
at android.database.AbstractCursor.getColumnIndexOrThrow(AbstractCursor.java:340)
at androidx.room.util.CursorUtil.getColumnIndexOrThrow(CursorUtil.java:108)
at app.tivi.data.daos.PopularDao_Impl$13.call(PopularDao_Impl.java:257)
at app.tivi.data.daos.PopularDao_Impl$13.call(PopularDao_Impl.java:249)
at androidx.room.CoroutinesRoom$Companion$createFlow$1$1.invokeSuspend(CoroutinesRoom.kt:81)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:241)
at androidx.room.TransactionExecutor$1.run(TransactionExecutor.java:45)
at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1412)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:285)
The columns listed in the exception have no relevance to the Flow query (they're from a completely different table). The table in question is also not mentioned in the generated calling code.
I *think* this is probably a cache invalidation issue, maybe in RoomSQLiteQuery.acquire, where the acquired query isn't properly invalidated so the "old" query is still being used?