Kotlinx.coroutines: RendezvousChannel cannot be cast to Function2

[eygraber]

Got this crash on an Android device running R8 in full mode, using 1.3.5:

Device Brand: BLU
Model: Life One X3
Android Version: 7.0

Fatal Exception: java.lang.ClassCastException: kotlinx.coroutines.channels.RendezvousChannel cannot be cast to kotlin.jvm.functions.Function2
       at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt$createCoroutineUnintercepted$$inlined$createCoroutineFromSuspendFunction$IntrinsicsKt__IntrinsicsJvmKt$4.invokeSuspend(IntrinsicsKt__IntrinsicsJvmKt.java:199)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(BaseContinuationImpl.java:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.java:56)
       at android.os.Handler.handleCallback(Handler.java:836)
       at android.os.Handler.dispatchMessage(Handler.java:103)
       at android.os.Looper.loop(Looper.java:203)
       at android.app.ActivityThread.main(ActivityThread.java:6251)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1063)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:924)

[qwwdfsad]

Please file the bug in Google bugtracker if it happens only in R8 full mode or only on specific devices, we, as a library, cannot affect it in any way

[eygraber]

I'm not sure if this has anything to do with R8. Just wanted to highlight that I am using it.

[qwwdfsad]

If this reproduces on a regular basis (e.g. in a regular JVM unit-test), please provide a reproducing snippet (that I can copy-paste and run), so we can investigate more thoroughly

[niqueco]

I don't know if this is related, but I'm getting lots of crashes like this one:

Fatal Exception: java.lang.ClassCastException: kotlinx.coroutines.channels.ProducerCoroutine cannot be cast to kotlin.jvm.functions.Function2
       at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt$createCoroutineUnintercepted$$inlined$createCoroutineFromSuspendFunction$IntrinsicsKt__IntrinsicsJvmKt$4.invokeSuspend(IntrinsicsKt__IntrinsicsJvmKt.java:199)
       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:571)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.java:738)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.java:678)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.java:665)

Using 1.3.6 version of coroutines library.

I coud not reproduce this locally.

[qwwdfsad]

This looks like a problem though.
Is it possible to provide a reproducing project then? Not a local example, but a whole github repo I can clone & run?

[eygraber]

I can't repro locally. Only getting notified about it through Crashlytics for my production Android app.

[niqueco]

I can't reproduce this either. But I get lots of crashes through Crashlytics. All of them Android 7.

[qwwdfsad]

It looks like it is triggered by incorrect ART compilation on specific devices, it is better to report to Google bugtracker.

We can't do much here, but if we'll know the problematic bytecode sequence, we could tweak our implementation a little to avoid triggering this invalid compilation sequence.

[niqueco]

Is there something that can be done to provide better feedback? These stack traces doesn't help with finding where the issue was so that the offending code can be reported.

[b95505017]

Not sure AGP 4.0 stable fix this or not: https://issuetracker.google.com/issues/154531810

[qwwdfsad]

Great! Please share your feedback and whether the problem has gone with newer AGP

[b95505017]

Sorry issue still exist. :(

[eygraber]

Just checked Crashlytics, and this issue is happening even with AGP 4.0 stable.

[zerny]

This looks like the device specific issue being tracked in https://issuetracker.google.com/issues/140347159

As noted in the tracker, we have not been able to pin point the exact bug in the VM and it is unlikely that we can make a workaround in the compiler without figuring that out. Even with knowledge of the VM bug, it may still be infeasible to make a general workaround. If you have a working reproduction, please to attach it to the issue as it could help in finding the exact VM bug. If you manage to find a workaround, such as a keep rule that results in code that does not hit the VM bug that would be useful to know also.