Fixed
Status Update
No update yet.
Comments
ra...@google.com
ra...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
[Deleted User] <[Deleted User]>
ra...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
https://android-review.googlesource.com/1288456
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
ra...@google.com
I still haven't been able to repro this locally, but did find that we were creating a single work request instance and enqueueing it multiple times. Perhaps that could cause this issue?
That should not result in this happening. Unless you are creating new WorkRequest ids which all get treated as new work requests.
[Deleted User] <[Deleted User]>
Unfortunately, we're not using WorkerFactory at all. Here's what our current code looks like:
private const val UNIQUE_WORK_NAME = "some_string"
internal class SomeClass(private val application: Application) {
private val constraints = Constraints.Builder()
.setRequiresBatteryNotLow(true)
.setRequiredNetworkType(NetworkType.CONNECTED)
.build()
private val workRequest = OneTimeWorkRequestBuilder<SomeWorker>()
.addTag(UNIQUE_WORK_NAME)
.setConstraints(constraints)
.build()
override suspend fun submitUploadRequest(force: Boolean) {
WorkManager.getInstance(application).enqueueUniqueWork(
UNIQUE_WORK_NAME,
if (force) ExistingWorkPolicy.REPLACE else ExistingWorkPolicy.KEEP,
workRequest
)
}
}
internal class SomeWorker(
appContext: Context,
params: WorkerParameters
) : CoroutineWorker(appContext, params) {
override suspend fun doWork(): Result = TODO("Omitted")
}
[Deleted User] <[Deleted User]>
Two more data points based on reports:
- We're only seeing this crash on Android 7.x
- Most common devices: Huawei Mate 10 lite, Huawei P9 lite, Samsung Galaxy S6
Still trying to repro - no luck so far with API 24 emulator.
ra...@google.com
We're only seeing this crash on Android 7.x
This makes sense. Because ConstraintTrackingWorker is only used in API 23-25.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 3d54e41768eb0bdfcad5e574cf6837cdd6520035
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Wed Nov 11 11:29:55 2020
Improve `ConstraintTrackingWorker.onStopped()`.
* We only stop a constraint tracking worker it was not already stopped.
Fixes:
Test: Added unit tests and integration tests. All existing tests pass.
Change-Id: Ic71b308d30024b98f5eb9cb23691583794254379
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.java
M work/integration-tests/testapp/src/main/res/layout/activity_main.xml
M work/integration-tests/testapp/src/main/res/values/strings.xml
M work/workmanager/src/androidTest/java/androidx/work/impl/workers/ConstraintTrackingWorkerTest.java
M work/workmanager/src/main/java/androidx/work/impl/workers/ConstraintTrackingWorker.java
https://android-review.googlesource.com/1496844
Branch: androidx-master-dev
commit 3d54e41768eb0bdfcad5e574cf6837cdd6520035
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Wed Nov 11 11:29:55 2020
Improve `ConstraintTrackingWorker.onStopped()`.
* We only stop a constraint tracking worker it was not already stopped.
Fixes:
Test: Added unit tests and integration tests. All existing tests pass.
Change-Id: Ic71b308d30024b98f5eb9cb23691583794254379
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.java
M work/integration-tests/testapp/src/main/res/layout/activity_main.xml
M work/integration-tests/testapp/src/main/res/values/strings.xml
M work/workmanager/src/androidTest/java/androidx/work/impl/workers/ConstraintTrackingWorkerTest.java
M work/workmanager/src/main/java/androidx/work/impl/workers/ConstraintTrackingWorker.java
tb...@gmail.com
I am also seeing something similar reported for a Huawei P8 Lite on Android 7.0
Fatal Exception: java.lang.StackOverflowError: stack size 1037KB
at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:447)
at androidx.work.impl.WorkerWrapper.tryCheckForInterruptionAndResolve(WorkerWrapper.java:419)
at androidx.work.impl.WorkerWrapper.interrupt(WorkerWrapper.java:375)
at androidx.work.impl.Processor.interrupt(Processor.java:331)
at androidx.work.impl.Processor.stopWork(Processor.java:188)
at androidx.work.impl.utils.StopWorkRunnable.run(StopWorkRunnable.java:73)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:776)
Is this related at all? Or is it a separate issue?
Description
This crash is happening in our production app. I haven't been able to reproduce it locally, but looking at WorkManager's source, the cause seems pretty straightforward.
Here's the source for
ListenableWorker.stopfor version 2.5.0-beta01:And here's the source for
ConstraintTrackingWorker.onStoppedfor version 2.5.0-beta01:stopcallsonStoppedwhich callsstopand so on. My assumption is that one of these two methods should check if the worker has already been stopped before calling each other again.