Lifecycle should not allow moving from INITIALIZED to DESTROYED [177924329]

Fixed

Bug

Status Update

No update yet.

Description

jb...@google.com

created issue #1

Jan 19, 2021 08:04PM

If you add an observers to a Lifecycle object and attempt to move that Lifecycle.State from INITIALIZED to DESTROYED, the following error will be thrown:

java.lang.IllegalStateException: no event down from INITIALIZED

If there is no observer, then the lifecycle state is moved without any error.

Moving the Lifecycle.State from INITIALIZED to DESTROYED should be consistent whether or not there is an observer on the Lifecycle.

Comments

il...@google.com <il...@google.com> Nov 18, 2021 10:12PM

Status: New

jb...@google.com <jb...@google.com> Feb 4, 2022 12:34AM

Assigned to jb...@google.com.

ap...@google.com <ap...@google.com> #2Feb 7, 2022 02:27PM

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?

il...@google.com <il...@google.com> #3Feb 7, 2022 06:05PM

Marked as fixed.

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

ad...@gmail.com <ad...@gmail.com> #4Feb 28, 2022 03:11PM

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.

l....@gmail.com <l....@gmail.com> #5Mar 31, 2022 09:02AM

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.

il...@google.com <il...@google.com> #6Mar 31, 2022 11:28PM

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)