Coroutine 1.6.0 ANR on Android 11 #3113
Comments
|
Ok so after some tests, I don't know why my original code with worker pool only ANR on Android 11. But following code will cause issues on Android. In an activity And the app will ANR as the delay never complete. This is probably logic as the main dispatcher is used for the delay but the main dispatcher is runblocking waiting too. This sounds like a major change that can impact many as it's easy to miss this side effect from just reading the changelog. Don't know if there's something to detect in Coroutines side to avoid this lock. Ping @qwwdfsad Calling System.setProperty("kotlinx.coroutines.main.delay", "false") early in app init does workaround the issue. |
|
Nice find. It makes sense that your code example would cause a deadlock if delay is waiting on the main thread: I'm not sure if this is a bug in the coroutines library as much as it is yet another reason to not use |
The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported:
* JavaFx timer doesn't really work outside the main thread
* The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks
* The latter issue was reported both by Android and internal JB Compose users
* The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour
The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release
Fixes #3113
Fixes #3106
…tlin#3131) The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported: * JavaFx timer doesn't really work outside the main thread * The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks * The latter issue was reported both by Android and internal JB Compose users * The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release Fixes Kotlin#3113 Fixes Kotlin#3106
|
We [Audiomack] just changed the method we initialized some of the native classes, and we began utilizing corountine. However, rather than lowering the amount of ANR, we see new ANR with the call of coroutines, which is peculiar to Android 11. Does it sound comparable to what you're pointing out here? Code for referencing. |
|
@qwwdfsad, Is this problem resolved? Alternatively, we have a workaround. Please share any information that will assist us in controlling the number of ANR. |
|
Should be fixed in 1.6.1 |
…tlin#3131) The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported: * JavaFx timer doesn't really work outside the main thread * The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks * The latter issue was reported both by Android and internal JB Compose users * The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release Fixes Kotlin#3113 Fixes Kotlin#3106
…tlin#3131) The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported: * JavaFx timer doesn't really work outside the main thread * The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks * The latter issue was reported both by Android and internal JB Compose users * The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release Fixes Kotlin#3113 Fixes Kotlin#3106
Took me a while to figure out but it seems the changes to
delayto use MainDispatcher have a side effect on Android 11 (And only Android 11).I have yet to build a repro but posting before in case there's something obvious.
In an activity in
onCreateI have a simple runBlocking (so on main thread ui) for a call that is nearly instant.That call use a workerPool on dispatchers.IO and at some point have a simple :
This works well on first start, but if the app is killed by OS or you swipe the app from the drawer (but don't use the kill) then further start will ANR with below trace.
ANR:
Since it's very specific to a version of Android I'm not sure there's something to be done at coroutines levels, and I'll try to increase the delay to see, but reporting in case the delay(1) with runBlocking on mainthread can trigger issues in other unseen cases.
The text was updated successfully, but these errors were encountered: