Fixed
Status Update
No update yet.
Comments
to...@gmail.com
Quickly tested with 1.6.50 it works too, and rebuilt just after with 1.6.51 to ensure no other caching issue or whatever and don't work again.
So regression in 1.6.51 by generating different bytecode for the ServiveLoaderMethods, see mappings and bytecode differences. Strangely 1.6.51 changes does not seems related to this kind of things.
1.6.50 : Mapping :
# compiler: R8
# compiler_version: 1.6.50
# min_api: 21
# pg_map_id: 3f57099
# common_typos_disable
$$ServiceLoaderMethods -> a:
java.util.Iterator $load0() -> a
java.util.Iterator $load1() -> b
1.6.50 : Bytecode :
.class public abstract synthetic La;
.super Ljava/lang/Object;
.source "ServiceLoader"
# direct methods
.method public static a()Ljava/util/Iterator;
.registers 3
const/4 v0, 0x1
:try_start_1
new-array v0, v0, [Lkotlinx/coroutines/CoroutineExceptionHandler;
const/4 v1, 0x0
new-instance v2, Lkotlinx/coroutines/android/AndroidExceptionPreHandler;
invoke-direct {v2}, Lkotlinx/coroutines/android/AndroidExceptionPreHandler;-><init>()V
aput-object v2, v0, v1
invoke-static {v0}, Ljava/util/Arrays;->asList([Ljava/lang/Object;)Ljava/util/List;
move-result-object v0
invoke-interface {v0}, Ljava/util/List;->iterator()Ljava/util/Iterator;
move-result-object v0
:try_end_13
.catchall {:try_start_1 .. :try_end_13} :catchall_14
return-object v0
:catchall_14
move-exception v0
new-instance v1, Ljava/util/ServiceConfigurationError;
invoke-virtual {v0}, Ljava/lang/Throwable;->getMessage()Ljava/lang/String;
move-result-object v2
invoke-direct {v1, v2, v0}, Ljava/util/ServiceConfigurationError;-><init>(Ljava/lang/String;Ljava/lang/Throwable;)V
throw v1
.end method
.method public static b()Ljava/util/Iterator;
.registers 3
const/4 v0, 0x1
:try_start_1
new-array v0, v0, [Lkotlinx/coroutines/internal/MainDispatcherFactory;
const/4 v1, 0x0
new-instance v2, Lkotlinx/coroutines/android/AndroidDispatcherFactory;
invoke-direct {v2}, Lkotlinx/coroutines/android/AndroidDispatcherFactory;-><init>()V
aput-object v2, v0, v1
invoke-static {v0}, Ljava/util/Arrays;->asList([Ljava/lang/Object;)Ljava/util/List;
move-result-object v0
invoke-interface {v0}, Ljava/util/List;->iterator()Ljava/util/Iterator;
move-result-object v0
:try_end_13
.catchall {:try_start_1 .. :try_end_13} :catchall_14
return-object v0
:catchall_14
move-exception v0
new-instance v1, Ljava/util/ServiceConfigurationError;
invoke-virtual {v0}, Ljava/lang/Throwable;->getMessage()Ljava/lang/String;
move-result-object v2
invoke-direct {v1, v2, v0}, Ljava/util/ServiceConfigurationError;-><init>(Ljava/lang/String;Ljava/lang/Throwable;)V
throw v1
.end method
1.6.51 : Mapping :
# compiler: R8
# compiler_version: 1.6.51
# min_api: 21
# pg_map_id: 4a54b9b
# common_typos_disable
$$ServiceLoaderMethods -> a:
java.util.Iterator $load0() -> a
1.6.51 : ByteCode :
.class public abstract synthetic La;
.super Ljava/lang/Object;
.source "ServiceLoader"
# direct methods
.method public static a()Ljava/util/Iterator;
.registers 3
const/4 v0, 0x1
:try_start_1
new-array v0, v0, [Lkotlinx/coroutines/CoroutineExceptionHandler;
const/4 v1, 0x0
new-instance v2, Lkotlinx/coroutines/android/AndroidExceptionPreHandler;
invoke-direct {v2}, Lkotlinx/coroutines/android/AndroidExceptionPreHandler;-><init>()V
aput-object v2, v0, v1
invoke-static {v0}, Ljava/util/Arrays;->asList([Ljava/lang/Object;)Ljava/util/List;
move-result-object v0
invoke-interface {v0}, Ljava/util/List;->iterator()Ljava/util/Iterator;
move-result-object v0
:try_end_13
.catchall {:try_start_1 .. :try_end_13} :catchall_14
return-object v0
:catchall_14
move-exception v0
new-instance v1, Ljava/util/ServiceConfigurationError;
invoke-virtual {v0}, Ljava/lang/Throwable;->getMessage()Ljava/lang/String;
move-result-object v2
invoke-direct {v1, v2, v0}, Ljava/util/ServiceConfigurationError;-><init>(Ljava/lang/String;Ljava/lang/Throwable;)V
throw v1
.end method
So regression in 1.6.51 by generating different bytecode for the ServiveLoaderMethods, see mappings and bytecode differences. Strangely 1.6.51 changes does not seems related to this kind of things.
1.6.50 : Mapping :
# compiler: R8
# compiler_version: 1.6.50
# min_api: 21
# pg_map_id: 3f57099
# common_typos_disable
$$ServiceLoaderMethods -> a:
java.util.Iterator $load0() -> a
java.util.Iterator $load1() -> b
1.6.50 : Bytecode :
.class public abstract synthetic La;
.super Ljava/lang/Object;
.source "ServiceLoader"
# direct methods
.method public static a()Ljava/util/Iterator;
.registers 3
const/4 v0, 0x1
:try_start_1
new-array v0, v0, [Lkotlinx/coroutines/CoroutineExceptionHandler;
const/4 v1, 0x0
new-instance v2, Lkotlinx/coroutines/android/AndroidExceptionPreHandler;
invoke-direct {v2}, Lkotlinx/coroutines/android/AndroidExceptionPreHandler;-><init>()V
aput-object v2, v0, v1
invoke-static {v0}, Ljava/util/Arrays;->asList([Ljava/lang/Object;)Ljava/util/List;
move-result-object v0
invoke-interface {v0}, Ljava/util/List;->iterator()Ljava/util/Iterator;
move-result-object v0
:try_end_13
.catchall {:try_start_1 .. :try_end_13} :catchall_14
return-object v0
:catchall_14
move-exception v0
new-instance v1, Ljava/util/ServiceConfigurationError;
invoke-virtual {v0}, Ljava/lang/Throwable;->getMessage()Ljava/lang/String;
move-result-object v2
invoke-direct {v1, v2, v0}, Ljava/util/ServiceConfigurationError;-><init>(Ljava/lang/String;Ljava/lang/Throwable;)V
throw v1
.end method
.method public static b()Ljava/util/Iterator;
.registers 3
const/4 v0, 0x1
:try_start_1
new-array v0, v0, [Lkotlinx/coroutines/internal/MainDispatcherFactory;
const/4 v1, 0x0
new-instance v2, Lkotlinx/coroutines/android/AndroidDispatcherFactory;
invoke-direct {v2}, Lkotlinx/coroutines/android/AndroidDispatcherFactory;-><init>()V
aput-object v2, v0, v1
invoke-static {v0}, Ljava/util/Arrays;->asList([Ljava/lang/Object;)Ljava/util/List;
move-result-object v0
invoke-interface {v0}, Ljava/util/List;->iterator()Ljava/util/Iterator;
move-result-object v0
:try_end_13
.catchall {:try_start_1 .. :try_end_13} :catchall_14
return-object v0
:catchall_14
move-exception v0
new-instance v1, Ljava/util/ServiceConfigurationError;
invoke-virtual {v0}, Ljava/lang/Throwable;->getMessage()Ljava/lang/String;
move-result-object v2
invoke-direct {v1, v2, v0}, Ljava/util/ServiceConfigurationError;-><init>(Ljava/lang/String;Ljava/lang/Throwable;)V
throw v1
.end method
1.6.51 : Mapping :
# compiler: R8
# compiler_version: 1.6.51
# min_api: 21
# pg_map_id: 4a54b9b
# common_typos_disable
$$ServiceLoaderMethods -> a:
java.util.Iterator $load0() -> a
1.6.51 : ByteCode :
.class public abstract synthetic La;
.super Ljava/lang/Object;
.source "ServiceLoader"
# direct methods
.method public static a()Ljava/util/Iterator;
.registers 3
const/4 v0, 0x1
:try_start_1
new-array v0, v0, [Lkotlinx/coroutines/CoroutineExceptionHandler;
const/4 v1, 0x0
new-instance v2, Lkotlinx/coroutines/android/AndroidExceptionPreHandler;
invoke-direct {v2}, Lkotlinx/coroutines/android/AndroidExceptionPreHandler;-><init>()V
aput-object v2, v0, v1
invoke-static {v0}, Ljava/util/Arrays;->asList([Ljava/lang/Object;)Ljava/util/List;
move-result-object v0
invoke-interface {v0}, Ljava/util/List;->iterator()Ljava/util/Iterator;
move-result-object v0
:try_end_13
.catchall {:try_start_1 .. :try_end_13} :catchall_14
return-object v0
:catchall_14
move-exception v0
new-instance v1, Ljava/util/ServiceConfigurationError;
invoke-virtual {v0}, Ljava/lang/Throwable;->getMessage()Ljava/lang/String;
move-result-object v2
invoke-direct {v1, v2, v0}, Ljava/util/ServiceConfigurationError;-><init>(Ljava/lang/String;Ljava/lang/Throwable;)V
throw v1
.end method
sg...@google.com
I am a bit surprised that you see this difference between 1.6.50 and 1.6.51, as the only change between the two is related to "checksum annotations" injected into the generated dex files, for debug builds, which are only used by apply changes (https://r8-review.googlesource.com/c/r8/+/45291 ). There should not be any changes for R8 release mode builds.
The same actually goes for 1.6.49 and 1.6.50 which only have changes to handling of checksums in debug builds.
The same actually goes for 1.6.49 and 1.6.50 which only have changes to handling of checksums in debug builds.
to...@gmail.com
Yes I've seen what the changes are supposed to do, yet here we are this is the only difference between the 2 dex files.
Android Studio and other dextools says that for 1.6.50 there's 34912 methods and for 1.6.51 there's 34911, this is the only missing piece and the APK now crash.
I've made numerous builds it's 100% reproductible. Maybe a bug during 1.6.51 build with some cache on your side.
Android Studio and other dextools says that for 1.6.50 there's 34912 methods and for 1.6.51 there's 34911, this is the only missing piece and the APK now crash.
I've made numerous builds it's 100% reproductible. Maybe a bug during 1.6.51 build with some cache on your side.
js...@google.com
I'm also not sure how 1.6.50 v.s. 1.6.51 can make that difference.
According to this:https://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/kotlinx-coroutines-android/resources/META-INF/com.android.tools/r8-from-1.6.0/coroutines.pro the rule is supposed to use `-assumenosideeffects` in lieu of `-assumevalues`. The side effect (?) is, with -assumenosideeffects, even field load (such as https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/jvm/src/internal/MainDispatchers.kt#L22 ) can be removed, which could change semantics of (class) initializers of the enclosing class. Hm, it's actually aiming for removing something more, while the diff is missing a synthetic service loader method... but at least we can try? :)
According to this:
to...@gmail.com
For the record as said in the first post those rules are not applied at all. Maybe because I use api in a module and don't have an implementation in the main module?
1.6 still loads the proguard configuration.
The resulting configuration only have :
# When editing this file, update the following files as well:
# - META-INF/com.android.tools/proguard/coroutines.pro
# - META-INF/proguard/coroutines.pro
-keep class kotlinx.coroutines.android.AndroidDispatcherFactory {*;}
And no trace of the assume forcing me to add it manually.
But now I've updated to AGP 3.6 Beta 4 cleaned every possible cache and rebooted and now 1.6.51 generate the proper code, I'm stunned as I can't understand what cache could possible generate such 100% reproductible issue.
1.6 still loads the proguard configuration.
The resulting configuration only have :
# When editing this file, update the following files as well:
# - META-INF/com.android.tools/proguard/
# - META-INF/proguard/
-keep class kotlinx.coroutines.android.AndroidDispatcherFactory {*;}
And no trace of the assume forcing me to add it manually.
But now I've updated to AGP 3.6 Beta 4 cleaned every possible cache and rebooted and now 1.6.51 generate the proper code, I'm stunned as I can't understand what cache could possible generate such 100% reproductible issue.
js...@google.com
Glad to hear that everything got back to normal. :) So, maybe we can close this as `not reproducible`, but will keep this open until we figure out how R8-version-specific rules are applied (and actually why *not* applied).
As perhttps://github.com/Kotlin/kotlinx.coroutines/commit/d6b0b0f90c601f86b2ac4030c02af4f4c4562ac1 , cc'ed Wojtek and Jake. Can anyone explain how user's app will pick up the right version of proguard configuration? Is it just for building coroutines ui module or is it supposed to be added to user app's configuration as well?
Or, as mentioned by Tolriq,
> Maybe because I use api in a module and don't have an implementation in the main module?
did it make a difference in this case?
As per
Or, as mentioned by Tolriq,
> Maybe because I use api in a module and don't have an implementation in the main module?
did it make a difference in this case?
to...@gmail.com
It's late but will do more tests tomorrow with rolling back AGP 3.6 B3 to be sure :)
to...@gmail.com
So reverted and done many many tests and can no more reproduce. While this is nice to have the issue magically solved this still trigger an important question:
What could have been cached and where that could generate this issue that was 100% reproductible until deleting almost everything and restarting to be sure there was no gradle daemon cache anywhere.
Having builds that are not 100% identical is not that nice, so knowing potential source to include those in my release build process would be nice.
What could have been cached and where that could generate this issue that was 100% reproductible until deleting almost everything and restarting to be sure there was no gradle daemon cache anywhere.
Having builds that are not 100% identical is not that nice, so knowing potential source to include those in my release build process would be nice.
sg...@google.com
Tolriq, where you using AGP 3.5.2 or AGB 3.6 beta 3 when you could reproduce the issue?
Ivan, are there any known issues relation to reproducible builds that might explain this?
Ivan, are there any known issues relation to reproducible builds that might explain this?
to...@gmail.com
I was using 3.6 beta 3. I do ./gradlew clean between each builds. Have tested also ./gradlew cleanBuildCache at that time.
When testing 3.6 beta 4, I also rebooted and fully removed the /caches/ folder from gradle too as additional steps. Since then no more visible issues. But those steps are very high time impacting so something narrower would be nice.
When testing 3.6 beta 4, I also rebooted and fully removed the /caches/ folder from gradle too as additional steps. Since then no more visible issues. But those steps are very high time impacting so something narrower would be nice.
ga...@google.com
There aren't any known caching issue. If you are using Gradle caching (org.gradle.caching=true in gradle.properties), you can run with --no-build-cache, followed by clean build. Running "cleanBuildCache" does not impact R8 pipeline (this is only for debug builds that match some conditions).
In general, for these issues diffing the build directories and recording the build logs is the best way to figure out the culprit. If you are running from the IDE, please make sure the same device is selected and the same varaint. E.g.:
- run build
- copy the build directories for every project
- run clean & run build
- diff the copy against the previous state
The only difference could be timestamps in jars, but we are working on removing those as well.
In general, for these issues diffing the build directories and recording the build logs is the best way to figure out the culprit. If you are running from the IDE, please make sure the same device is selected and the same varaint. E.g.:
- run build
- copy the build directories for every project
- run clean & run build
- diff the copy against the previous state
The only difference could be timestamps in jars, but we are working on removing those as well.
to...@gmail.com
Hum too bad that I can no more reproduce to have the definitive answer :(
Anyway will add the --no-build-cache to my release scripts and hope it's enough.
Just need the Jake or Wojtek answer about conditional R8 rules for 1.6 to see if I should report that other issue too.
Anyway will add the --no-build-cache to my release scripts and hope it's enough.
Just need the Jake or Wojtek answer about conditional R8 rules for 1.6 to see if I should report that other issue too.
wk...@google.com
All logic for picking the right rules from directories, extracting them and applying are in AGP (3.6.0+), R8 and Proguard don't know or care about it, they just use whatever AGP passes in in arguments. So the rule targeting should work regardless of R8 version.
We never properly launched the feature publicly, and so for now coroutines is the only user. If it's not working you can let me know the details and I can investigate.
We never properly launched the feature publicly, and so for now coroutines is the only user. If it's not working you can let me know the details and I can investigate.
to...@gmail.com
Well then it's not working:
AGP 3.6 beta 3 / 4 + Coroutines 1.3.2 loaded as api() in a module + R8 1.6.42 to 51
The resulting applied configuration is
# When editing this file, update the following files as well:
# - META-INF/com.android.tools/proguard/coroutines.pro
# - META-INF/proguard/coroutines.pro
-keep class kotlinx.coroutines.android.AndroidDispatcherFactory {*;}
Meaning it takeshttps://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/kotlinx-coroutines-android/resources/META-INF/com.android.tools/r8-upto-1.6.0/coroutines.pro when it should have taken https://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/kotlinx-coroutines-android/resources/META-INF/com.android.tools/r8-from-1.6.0/coroutines.pro
So it properly switch to the com.android.tools stuff but fails at identifying R8 version?
AGP 3.6 beta 3 / 4 + Coroutines 1.3.2 loaded as api() in a module + R8 1.6.42 to 51
The resulting applied configuration is
# When editing this file, update the following files as well:
# - META-INF/com.android.tools/proguard/
# - META-INF/proguard/
-keep class kotlinx.coroutines.android.AndroidDispatcherFactory {*;}
Meaning it takes
So it properly switch to the com.android.tools stuff but fails at identifying R8 version?
wk...@google.com
You're right, there seems to be a problem with version code comparisons. Looking into it
uc...@google.com
js...@google.com
wk...@google.com
Fix is in for 3.6. This was an embarrassing parsing bug, sorry for that everyone!
Has there been anything else in this bug or was that just it and I should close it? There was something about non reproducible builds for example, do you want to split that into another bug?
Has there been anything else in this bug or was that just it and I should close it? There was something about non reproducible builds for example, do you want to split that into another bug?
to...@gmail.com
I'll reopen one when I can reproduce again if ever.
But to avoid spamming another issue you may want to check the #5 comment about assumenosideeffects and assumevalues ?
Since auto rules did not work I use the Jake version
https://github.com/Kotlin/kotlinx.coroutines/issues/1231#issuecomment-499300105
That use assumevalues maybe it worth checking and be clear about the correct one?
But to avoid spamming another issue you may want to check the #5 comment about assumenosideeffects and assumevalues ?
Since auto rules did not work I use the Jake version
That use assumevalues maybe it worth checking and be clear about the correct one?
yo...@monday.com
Hey Folks
I'm with AGP 3.6.1 with coroutines 1.3.3 and following R8 rules:
# ServiceLoader support
-keepnames class kotlinx.coroutines.internal.MainDispatcherFactory {}
-keepnames class kotlinx.coroutines.CoroutineExceptionHandler {}
-keepnames class kotlinx.coroutines.android.AndroidExceptionPreHandler {}
-keepnames class kotlinx.coroutines.android.AndroidDispatcherFactory {}
# Most of volatile fields are updated with AFU and should not be mangled
-keepclassmembernames class kotlinx.** {
volatile <fields>;
}
# Same story for the standard library's SafeContinuation that also uses AtomicReferenceFieldUpdater
-keepclassmembernames class kotlin.coroutines.SafeContinuation {
volatile <fields>;
}
and we faced this exception that is similar to what we have here in bug
Fatal Exception: java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize
at kotlinx.coroutines.internal.MissingMainCoroutineDispatcher.missing(MissingMainCoroutineDispatcher.java:95)
at kotlinx.coroutines.internal.MissingMainCoroutineDispatcher.isDispatchNeeded(MissingMainCoroutineDispatcher.java:69)
at kotlinx.coroutines.DispatchedContinuationKt.resumeCancellableWith(DispatchedContinuationKt.java:268)
at kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable(CancellableKt.java:26)
at kotlinx.coroutines.CoroutineStart.invoke(CoroutineStart.java:109)
at kotlinx.coroutines.AbstractCoroutine.start(AbstractCoroutine.java:158)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.launch(BuildersKt__Builders_commonKt.java:54)
at kotlinx.coroutines.BuildersKt.launch(BuildersKt.java:1)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.launch$default(BuildersKt__Builders_commonKt.java:47)
at kotlinx.coroutines.BuildersKt.launch$default(BuildersKt.java:1)
at com.monday.core.BaseTaskRunner.run(BaseTaskRunner.java:100)
at com.dapulse.dapulse.refactor.feature.notifications.ui.NotificationListAdapter.handleNewDataPayload(NotificationListAdapter.java:91)
at com.dapulse.dapulse.refactor.feature.notifications.ui.NotificationListAdapter.lambda$setupMailBox$0(NotificationListAdapter.java:84)
at com.dapulse.dapulse.refactor.feature.notifications.ui.-$$Lambda$NotificationListAdapter$WAZEsTQp9Niqg-cXEd4I8dfwAjA.invoke(-.java:4)
at com.dapulse.dapulse.refactor.layers.data.board.mailBox.MailBox$startReceiveMail$1.invokeSuspend(MailBox.java:13)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(BaseContinuationImpl.java:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.java:56)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:561)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.java:727)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.java:667)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.java:655)
Caused by java.lang.ClassCastException: kotlinx.coroutines.android.AndroidExceptionPreHandler cannot be cast to kotlinx.coroutines.internal.MainDispatcherFactory
at kotlinx.coroutines.internal.MainDispatcherLoader.loadMainDispatcher(MainDispatcherLoader.java:127)
at kotlinx.coroutines.internal.MainDispatcherLoader.<clinit>(MainDispatcherLoader.java:18)
at kotlinx.coroutines.Dispatchers.getMain(Dispatchers.java:58)
at com.monday.core.MainThreadTaskRunner.<init>(MainThreadTaskRunner.java:131)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.view.viewPager.NotificationsViewPagerAdapter.<init>(NotificationsViewPagerAdapter.java:32)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.view.NotificationsFragment.initViewPager(NotificationsFragment.java:204)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.view.NotificationsFragment.access$initViewPager(NotificationsFragment.java:41)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.view.NotificationsFragment$setupPresenterObservationsOnCreateView$1.invoke(NotificationsFragment.java:102)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.view.NotificationsFragment$setupPresenterObservationsOnCreateView$1.invoke(NotificationsFragment.java:41)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.viewModel.NotificationsViewModel$observeTabsData$2.onChanged(NotificationsViewModel.java:70)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.viewModel.NotificationsViewModel$observeTabsData$2.onChanged(NotificationsViewModel.java:14)
at androidx.lifecycle.LiveData.considerNotify(LiveData.java:131)
at androidx.lifecycle.LiveData.dispatchingValue(LiveData.java:144)
at androidx.lifecycle.LiveData$ObserverWrapper.activeStateChanged(LiveData.java:442)
at androidx.lifecycle.LiveData$LifecycleBoundObserver.onStateChanged(LiveData.java:394)
at androidx.lifecycle.LifecycleRegistry$ObserverWithState.dispatchEvent(LifecycleRegistry.java:361)
at androidx.lifecycle.LifecycleRegistry.forwardPass(LifecycleRegistry.java:300)
at androidx.lifecycle.LifecycleRegistry.sync(LifecycleRegistry.java:339)
at androidx.lifecycle.LifecycleRegistry.moveToState(LifecycleRegistry.java:145)
at androidx.lifecycle.LifecycleRegistry.handleLifecycleEvent(LifecycleRegistry.java:131)
at androidx.fragment.app.Fragment.performStart(Fragment.java:2637)
at androidx.fragment.app.FragmentManagerImpl.moveToState(FragmentManagerImpl.java:915)
at androidx.fragment.app.FragmentManagerImpl.addAddedFragments(FragmentManagerImpl.java:2100)
at androidx.fragment.app.FragmentManagerImpl.executeOpsTogether(FragmentManagerImpl.java:1874)
at androidx.fragment.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManagerImpl.java:1830)
at androidx.fragment.app.FragmentManagerImpl.execPendingActions(FragmentManagerImpl.java:1727)
at androidx.fragment.app.FragmentManagerImpl$2.run(FragmentManagerImpl.java:150)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6527)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
cleaning the cache and rebuild solve the issue for now but it's returning time to time in our instrumentation tests on release builds:
java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize
FATAL EXCEPTION: DefaultDispatcher-worker-1
Process: com.monday.monday, PID: 10833
java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize
at rs5.n(MainDispatchers.kt:3)
at rs5.b(MainDispatchers.kt:1)
at ap5.a(DispatchedContinuation.kt:3)
at xs5.a(Unknown Source:8)
at sn5.a(AbstractCoroutine.kt:14)
at kotlinx.coroutines.BuildersKt.launch$default(Unknown Source:7)
at t45.run(TaskRunner.kt:1)
at d$l.invoke(NativeSignupPresenter.kt:5)
at d$d.invokeSuspend(NativeSignupPresenter.kt:17)
at d$d.invoke(NativeSignupPresenter.kt:2)
at v45$a.invokeSuspend(TaskRunner.kt:5)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
at cp5.run(DispatchedTask.kt:15)
at et5.a(CoroutineScheduler.kt:25)
at et5$a.run(CoroutineScheduler.kt:15)
Caused by: java.lang.ClassCastException: kotlinx.coroutines.android.AndroidExceptionPreHandler cannot be cast to kotlinx.coroutines.internal.MainDispatcherFactory
at qs5.a(MainDispatchers.kt:12)
at qs5.<clinit>(MainDispatchers.kt:5)
at ep5.a(Dispatchers.kt:1)
at l55.<init>(TaskRunner.kt:1)
at ly0.get(SignupModule_ProvidePresenter$app_mondayStagingFactory.java:3)
at gb5.get(DoubleCheck.java:6)
at l03$d.inject(DaggerAppComponent.java:6)
at dagger.android.DispatchingAndroidInjector.maybeInject(DispatchingAndroidInjector.java:6)
at com.dapulse.dapulse.refactor.regression.signup.SignupTest$$special$$inlined$getSignupDataProviderTestRuleProvider$1$1$1.inject(ActivityUtil.kt:17)
at com.dapulse.dapulse.refactor.regression.signup.SignupTest$$special$$inlined$getSignupDataProviderTestRuleProvider$1$1$1.inject(Unknown Source:2)
at dagger.android.DispatchingAndroidInjector.maybeInject(DispatchingAndroidInjector.java:6)
at com.dapulse.dapulse.DaPulseApp.a(DaPulseApp.java:8)
at bv.inject(Unknown Source:2)
at zm4.a(UserManager.java:306)
at zm4.b(UserManager.java:11)
at com.dapulse.dapulse.refactor.feature.native_signup.NativeSignupActivity.onCreate(NativeSignupActivity.java:3)
at android.app.Activity.performCreate(Activity.java:7144)
at android.app.Activity.performCreate(Activity.java:7135)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271)
at androidx.test.runner.MonitoringInstrumentation.callActivityOnCreate(MonitoringInstrumentation.java:2)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2931)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3086)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1816)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6718)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
I'm with AGP 3.6.1 with coroutines 1.3.3 and following R8 rules:
# ServiceLoader support
-keepnames class kotlinx.coroutines.internal.MainDispatcherFactory {}
-keepnames class kotlinx.coroutines.CoroutineExceptionHandler {}
-keepnames class kotlinx.coroutines.android.AndroidExceptionPreHandler {}
-keepnames class kotlinx.coroutines.android.AndroidDispatcherFactory {}
# Most of volatile fields are updated with AFU and should not be mangled
-keepclassmembernames class kotlinx.** {
volatile <fields>;
}
# Same story for the standard library's SafeContinuation that also uses AtomicReferenceFieldUpdater
-keepclassmembernames class kotlin.coroutines.SafeContinuation {
volatile <fields>;
}
and we faced this exception that is similar to what we have here in bug
Fatal Exception: java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize
at kotlinx.coroutines.internal.MissingMainCoroutineDispatcher.missing(MissingMainCoroutineDispatcher.java:95)
at kotlinx.coroutines.internal.MissingMainCoroutineDispatcher.isDispatchNeeded(MissingMainCoroutineDispatcher.java:69)
at kotlinx.coroutines.DispatchedContinuationKt.resumeCancellableWith(DispatchedContinuationKt.java:268)
at kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable(CancellableKt.java:26)
at kotlinx.coroutines.CoroutineStart.invoke(CoroutineStart.java:109)
at kotlinx.coroutines.AbstractCoroutine.start(AbstractCoroutine.java:158)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.launch(BuildersKt__Builders_commonKt.java:54)
at kotlinx.coroutines.BuildersKt.launch(BuildersKt.java:1)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.launch$default(BuildersKt__Builders_commonKt.java:47)
at kotlinx.coroutines.BuildersKt.launch$default(BuildersKt.java:1)
at com.monday.core.BaseTaskRunner.run(BaseTaskRunner.java:100)
at com.dapulse.dapulse.refactor.feature.notifications.ui.NotificationListAdapter.handleNewDataPayload(NotificationListAdapter.java:91)
at com.dapulse.dapulse.refactor.feature.notifications.ui.NotificationListAdapter.lambda$setupMailBox$0(NotificationListAdapter.java:84)
at com.dapulse.dapulse.refactor.feature.notifications.ui.-$$Lambda$NotificationListAdapter$WAZEsTQp9Niqg-cXEd4I8dfwAjA.invoke(-.java:4)
at com.dapulse.dapulse.refactor.layers.data.board.mailBox.MailBox$startReceiveMail$1.invokeSuspend(MailBox.java:13)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(BaseContinuationImpl.java:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.java:56)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:561)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.java:727)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.java:667)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.java:655)
Caused by java.lang.ClassCastException: kotlinx.coroutines.android.AndroidExceptionPreHandler cannot be cast to kotlinx.coroutines.internal.MainDispatcherFactory
at kotlinx.coroutines.internal.MainDispatcherLoader.loadMainDispatcher(MainDispatcherLoader.java:127)
at kotlinx.coroutines.internal.MainDispatcherLoader.<clinit>(MainDispatcherLoader.java:18)
at kotlinx.coroutines.Dispatchers.getMain(Dispatchers.java:58)
at com.monday.core.MainThreadTaskRunner.<init>(MainThreadTaskRunner.java:131)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.view.viewPager.NotificationsViewPagerAdapter.<init>(NotificationsViewPagerAdapter.java:32)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.view.NotificationsFragment.initViewPager(NotificationsFragment.java:204)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.view.NotificationsFragment.access$initViewPager(NotificationsFragment.java:41)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.view.NotificationsFragment$setupPresenterObservationsOnCreateView$1.invoke(NotificationsFragment.java:102)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.view.NotificationsFragment$setupPresenterObservationsOnCreateView$1.invoke(NotificationsFragment.java:41)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.viewModel.NotificationsViewModel$observeTabsData$2.onChanged(NotificationsViewModel.java:70)
at com.dapulse.dapulse.refactor.feature.notifications.mvpvm.viewModel.NotificationsViewModel$observeTabsData$2.onChanged(NotificationsViewModel.java:14)
at androidx.lifecycle.LiveData.considerNotify(LiveData.java:131)
at androidx.lifecycle.LiveData.dispatchingValue(LiveData.java:144)
at androidx.lifecycle.LiveData$ObserverWrapper.activeStateChanged(LiveData.java:442)
at androidx.lifecycle.LiveData$LifecycleBoundObserver.onStateChanged(LiveData.java:394)
at androidx.lifecycle.LifecycleRegistry$ObserverWithState.dispatchEvent(LifecycleRegistry.java:361)
at androidx.lifecycle.LifecycleRegistry.forwardPass(LifecycleRegistry.java:300)
at androidx.lifecycle.LifecycleRegistry.sync(LifecycleRegistry.java:339)
at androidx.lifecycle.LifecycleRegistry.moveToState(LifecycleRegistry.java:145)
at androidx.lifecycle.LifecycleRegistry.handleLifecycleEvent(LifecycleRegistry.java:131)
at androidx.fragment.app.Fragment.performStart(Fragment.java:2637)
at androidx.fragment.app.FragmentManagerImpl.moveToState(FragmentManagerImpl.java:915)
at androidx.fragment.app.FragmentManagerImpl.addAddedFragments(FragmentManagerImpl.java:2100)
at androidx.fragment.app.FragmentManagerImpl.executeOpsTogether(FragmentManagerImpl.java:1874)
at androidx.fragment.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManagerImpl.java:1830)
at androidx.fragment.app.FragmentManagerImpl.execPendingActions(FragmentManagerImpl.java:1727)
at androidx.fragment.app.FragmentManagerImpl$2.run(FragmentManagerImpl.java:150)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6527)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
cleaning the cache and rebuild solve the issue for now but it's returning time to time in our instrumentation tests on release builds:
java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize
FATAL EXCEPTION: DefaultDispatcher-worker-1
Process: com.monday.monday, PID: 10833
java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize
at rs5.n(MainDispatchers.kt:3)
at rs5.b(MainDispatchers.kt:1)
at ap5.a(DispatchedContinuation.kt:3)
at xs5.a(Unknown Source:8)
at sn5.a(AbstractCoroutine.kt:14)
at kotlinx.coroutines.BuildersKt.launch$default(Unknown Source:7)
at t45.run(TaskRunner.kt:1)
at d$l.invoke(NativeSignupPresenter.kt:5)
at d$d.invokeSuspend(NativeSignupPresenter.kt:17)
at d$d.invoke(NativeSignupPresenter.kt:2)
at v45$a.invokeSuspend(TaskRunner.kt:5)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
at cp5.run(DispatchedTask.kt:15)
at et5.a(CoroutineScheduler.kt:25)
at et5$a.run(CoroutineScheduler.kt:15)
Caused by: java.lang.ClassCastException: kotlinx.coroutines.android.AndroidExceptionPreHandler cannot be cast to kotlinx.coroutines.internal.MainDispatcherFactory
at qs5.a(MainDispatchers.kt:12)
at qs5.<clinit>(MainDispatchers.kt:5)
at ep5.a(Dispatchers.kt:1)
at l55.<init>(TaskRunner.kt:1)
at ly0.get(SignupModule_ProvidePresenter$app_mondayStagingFactory.java:3)
at gb5.get(DoubleCheck.java:6)
at l03$d.inject(DaggerAppComponent.java:6)
at dagger.android.DispatchingAndroidInjector.maybeInject(DispatchingAndroidInjector.java:6)
at com.dapulse.dapulse.refactor.regression.signup.SignupTest$$special$$inlined$getSignupDataProviderTestRuleProvider$1$1$1.inject(ActivityUtil.kt:17)
at com.dapulse.dapulse.refactor.regression.signup.SignupTest$$special$$inlined$getSignupDataProviderTestRuleProvider$1$1$1.inject(Unknown Source:2)
at dagger.android.DispatchingAndroidInjector.maybeInject(DispatchingAndroidInjector.java:6)
at com.dapulse.dapulse.DaPulseApp.a(DaPulseApp.java:8)
at bv.inject(Unknown Source:2)
at zm4.a(UserManager.java:306)
at zm4.b(UserManager.java:11)
at com.dapulse.dapulse.refactor.feature.native_signup.NativeSignupActivity.onCreate(NativeSignupActivity.java:3)
at android.app.Activity.performCreate(Activity.java:7144)
at android.app.Activity.performCreate(Activity.java:7135)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271)
at androidx.test.runner.MonitoringInstrumentation.callActivityOnCreate(MonitoringInstrumentation.java:2)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2931)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3086)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1816)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6718)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Description
# Ensure the custom, fast service loader implementation is removed.
-assumevalues class kotlinx.coroutines.internal.MainDispatcherLoader {
boolean FAST_SERVICE_LOADER_ENABLED return false;
}
-checkdiscard class kotlinx.coroutines.internal.FastServiceLoader
I need to add this rule manually as it seems that 1.6 still does not support the differential rules loading that was added at
Anyway everything works fine with 1.6.49 but when updating to 1.6.51 I got following crash :
java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize
at g4.a.r2.o.g(MainDispatchers.kt:3)
at g4.a.r2.o.a(MainDispatchers.kt:1)
at g4.a.r0.a(Dispatched.kt:2)
at c4.z.s0.b(ViewGroupUtilsApi14.java:40)
at g4.a.a.a(AbstractCoroutine.kt:16)
at c4.z.s0.b(ViewGroupUtilsApi14.java:64)
at l4.a.a.a.m.b2.j.c(xxxx.kt:51)
at l4.a.a.a.m.b2.j.b(xxxx.kt:2)
at l4.a.a.a.m.z1.a.c(JobManager.kt:9)
at f4.s.o.a.a.a(ContinuationImpl.kt:2)
at g4.a.s0.run(Dispatched.kt:19)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
Caused by: java.lang.ClassCastException: kotlinx.coroutines.android.AndroidExceptionPreHandler cannot be cast to kotlinx.coroutines.internal.MainDispatcherFactory
at g4.a.r2.n.<clinit>(MainDispatchers.kt:14)
at g4.a.t0.a(Dispatchers.kt:1)
Can provide APK and mapping to Jinseong if necessary.