Outer transaction must be marked successfully in WorkerWrapper [175944460]

Fixed

Bug

Status Update

No update yet.

Description

ac...@gmail.com

created issue #1

Dec 19, 2020 03:49AM

Component used: WorkManager
Version used: all version including 2.5.0-rc01
Devices/Android versions reproduced on: Motorola G 7.0 (SDK 24), 7.1 (SDK 25)

Related source code:

https://android.googlesource.com/platform/frameworks/support/+/androidx-master-dev/work/workmanager/src/main/java/androidx/work/impl/WorkerWrapper.java#193
mWorkDatabase.setTransactionSuccessful() must be called after calling resolve(true) line 193. Nested transactions will be rolled back if the outer transaction isn't marked as successful.
This behavior causes crashes on Motorola devices with 7.0/7.1

See crash report from Google Play for Motorola devices.

Fri Dec 18 2020 19:49:24 GMT-0800 (Pacific Standard Time).png

145 KB

View

Download

Comments

ra...@google.com <ra...@google.com> Dec 21, 2020 10:58PM

Assigned to ra...@google.com.

ra...@google.com <ra...@google.com> #2Dec 25, 2020 10:10PM

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?

ap...@google.com <ap...@google.com> #3Dec 28, 2020 05:10PM

Marked as fixed.

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

ac...@gmail.com <ac...@gmail.com> #4Dec 28, 2020 07:00PM

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.

ra...@google.com <ra...@google.com> #5Dec 28, 2020 07:02PM

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.

ac...@gmail.com <ac...@gmail.com> #6Mar 16, 2021 06:47PM

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)

Issue 175944460