Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception during IR lowering #301

Closed
ejektaflex opened this issue Jan 22, 2021 · 29 comments
Closed

Exception during IR lowering #301

ejektaflex opened this issue Jan 22, 2021 · 29 comments
Assignees
Labels
compiler Compiler plugin related

Comments

@ejektaflex
Copy link

ejektaflex commented Jan 22, 2021

I've been trying to get JetBrains Compose to work with my existing project, but it keeps on giving me this error:

java.lang.IllegalStateException: Backend Internal error: Exception during IR lowering
File being compiled: C:/Users/20047/IdeaProjects/TradisAgnostic/src/main/kotlin/io/ejekta/core/struct/GameRegistry.kt
The root cause java.lang.AssertionError was thrown at: org.jetbrains.kotlin.backend.common.ir.IrUtilsKt.copyValueParametersToStatic(IrUtils.kt:245)
	at org.jetbrains.kotlin.backend.common.CodegenUtil.reportBackendException(CodegenUtil.kt:239)
	at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(PhaseBuilders.kt:124)
	at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(PhaseBuilders.kt:112)
	at org.jetbrains.kotlin.backend.common.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:94)
	at org.jetbrains.kotlin.backend.common.phaser.CompositePhase.invoke(PhaseBuilders.kt:30)
	at org.jetbrains.kotlin.backend.common.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:94)
	at org.jetbrains.kotlin.backend.common.phaser.CompilerPhaseKt.invokeToplevel(CompilerPhase.kt:41)
	at org.jetbrains.kotlin.backend.jvm.JvmLower.lower(JvmLower.kt:395)
	at org.jetbrains.kotlin.backend.jvm.JvmBackendFacade.doGenerateFilesInternal$backend_jvm(JvmBackendFacade.kt:138)
	at org.jetbrains.kotlin.backend.jvm.JvmBackendFacade.doGenerateFilesInternal$backend_jvm$default(JvmBackendFacade.kt:125)
	at org.jetbrains.kotlin.backend.jvm.JvmBackendFacade.doGenerateFiles(JvmBackendFacade.kt:112)
	at org.jetbrains.kotlin.backend.jvm.JvmIrCodegenFactory.generateModule(JvmIrCodegenFactory.kt:40)
	at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.compileCorrectFiles(KotlinCodegenFacade.java:35)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.generate(KotlinToJVMBytecodeCompiler.kt:647)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli(KotlinToJVMBytecodeCompiler.kt:210)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli$default(KotlinToJVMBytecodeCompiler.kt:162)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:169)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:52)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:88)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:44)
	at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:98)
	at org.jetbrains.kotlin.incremental.IncrementalJvmCompilerRunner.runCompiler(IncrementalJvmCompilerRunner.kt:371)
	at org.jetbrains.kotlin.incremental.IncrementalJvmCompilerRunner.runCompiler(IncrementalJvmCompilerRunner.kt:105)
	at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compileIncrementally(IncrementalCompilerRunner.kt:249)
	at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.access$compileIncrementally(IncrementalCompilerRunner.kt:38)
	at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner$compile$2.invoke(IncrementalCompilerRunner.kt:80)
	at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compile(IncrementalCompilerRunner.kt:92)
	at org.jetbrains.kotlin.daemon.CompileServiceImplBase.execIncrementalCompiler(CompileServiceImpl.kt:602)
	at org.jetbrains.kotlin.daemon.CompileServiceImplBase.access$execIncrementalCompiler(CompileServiceImpl.kt:93)
	at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1644)
	at jdk.internal.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
	at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
	at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

This is with build 0.3.0-build141 and Kotlin 1.4.21.
Attached is what GameRegistry.kt looks like.

GameRegistry.txt

@olonho
Copy link
Contributor

olonho commented Jan 22, 2021

Please retry with Compose 0.0.0-vsync-build30 and Kotlin 1.4.21-2.

@olonho olonho added the compiler Compiler plugin related label Jan 22, 2021
@ejektaflex
Copy link
Author

I switched to those versions, and I get the same error. I did also verify that they were the correct versions, so yes it is still happening.

@jimgoog
Copy link
Collaborator

jimgoog commented Jan 22, 2021

I don't even see any Composable functions in that file you attached and Compose is not on your stack trace. This doesn't preclude Compose from being the source of the problem, but it does mean that the source of the problem isn't obvious.

The file you posted isn't too useful because it doesn't even build without the dependencies referenced in that file. Can you create a minimal repro project such that the same error occurs? That will allow us to investigate further.

@ejektaflex
Copy link
Author

@jimgoog
Copy link
Collaborator

jimgoog commented Jan 23, 2021

@olonho You were correct in your speculation that it was kotlin-serialization related, removing the kotlin-serialization plugin causes the build to succeed. How confident are we that the 1.4.21-2 build actually fixed the serialization issue?

Also, how old is the 0.0.0-vsync-build30 branch? Just a shot in the dark, but we did remove our usage of deepCopyWithSymbols from Compose on Wednesday night your time, so if the last merge from androidx/compose is more than 48 hours ago, it might be worth doing another merge and seeing if that fixes it.

Otherwise, sounds like perhaps this repro should be passed to the Kotlin serialization team?

I applied the following diff on top of @ejektaflex repository, got the same error message @ejektaflex did.

jsproch-macbookpro6:ComposeCrash jsproch$ git diff
diff --git a/build.gradle.kts b/build.gradle.kts
index 2bba432..5755ff3 100644
--- a/build.gradle.kts
+++ b/build.gradle.kts
@@ -2,12 +2,12 @@ import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
 import org.jetbrains.compose.compose
 
 plugins {
-    id("org.jetbrains.kotlin.jvm") version "1.4.21"
-    id("org.jetbrains.kotlin.plugin.serialization") version "1.4.21"
-    id("org.jetbrains.compose") version "0.3.0-build141"
+    id("org.jetbrains.kotlin.jvm") version "1.4.21-2"
+    id("org.jetbrains.kotlin.plugin.serialization") version "1.4.21-2"
+    id("org.jetbrains.compose") version "0.0.0-vsync-build30"
 }
 
-val kotlinVersion = "1.4.21"
+val kotlinVersion = "1.4.21-2"
 val ktorVersion = "1.5.0"
 
 repositories {
@@ -32,3 +32,12 @@ dependencies {
 
 }
 
+
+// Allow forcing of kotlin version
+tasks.withType(KotlinCompile::class.java).configureEach {
+    kotlinOptions {
+        freeCompilerArgs = freeCompilerArgs + listOf("-P", "plugin:androidx.compose.compiler.plugins.kotlin:suppressKotlinVersionCompatibilityCheck=true")
+    }
+}
+
+
diff --git a/gradlew b/gradlew
old mode 100644
new mode 100755

@sandwwraith
Copy link
Member

It's indeed the conflict between compose and kotlinx.serialization — because Compose copies the whole IR tree, serialization plugin gets incorrect accessors for some declarations.

In this particular case, the workaround is to remove any private var/vals (GameRegistry.autoKey in the reproducer)

@jimgoog
Copy link
Collaborator

jimgoog commented Jan 29, 2021

@sandwwraith I just checked with 0.3.0-build143. We were previously copying the whole IR tree (using deepCopyWithSymbols) but we have since removed all invocations of deepCopyWithSymbols, so I think we are no longer copying the entire tree, yet this crash is still occurring.

Where is kotlinx.serialization getting the incorrect accessors from? Is the Compose Compiler doing something wrong here? Intuitively it seems like both plugins get IR in and IR out, as long as the IR is well-formed when it comes out of the plugin, then the other plugin should be able to operate without issue. Is our plugin somehow producing illegal IR?

@sandwwraith
Copy link
Member

Since $serializer is a nested class, and autoKey is private var, when plugin generates instruction to read it, compiler automatically inserts access$getautoKey function. When the IR tree is later copied (?) or manipulated in some other way, bodies of functions generated by serialization plugin are not updated for some reason and refer old access function that is not present in tree anymore, generating various failures. I'm not sure which plugin is to blame — I've tried to manipulate IR as directly as possible in my previous fixes, but it is for some reason is not enough. I'll continue to investigate; it would be nice if you look at this from your point of view and possibly find some clues to share with me.

@jimgoog
Copy link
Collaborator

jimgoog commented Jan 29, 2021

Leland mentioned that if it is on the Compose side, the type remapping seems like a possible suspect.
The line it fails on is: assert(dispatchReceiverType!!.isSubtypeOfClass(originalDispatchReceiver.type.classOrNull!!)) so for some reason maybe the two types are the "same type" but just one hasn't been remapped to the new symbol for that type.

Let us know if you find that Compose is somehow to blame. I imagine that as more and more plugins get written, weird compatibility bugs are going to become more common unless there is some sort of validator that plugin authors can run on their output to verify their plugin is producing acceptable code, because it's still not clear who or why is responsible for this crash. Certainly some expectation is violated by one of the plugins.

@linroid
Copy link

linroid commented Feb 2, 2021

Not sure if this is helpful and it's the same root cause with this issue: I encounter the same stack trace crash when I try to refactor a method name or change its parameter type from non-null to nullable, only one special method has this problem.

The problem goes away after I execute clean task, but it comes back once I do the rename operation again.

My project doesn't depend on kotlin serializer but it depends on Compose(Android).

LMK if you need more information.

versions:
kotlin: 1.4.21-2
compose: 1.0.0-alpha11

@akurasov
Copy link
Contributor

akurasov commented Aug 6, 2021

Currently it is prohibited to use Compose and Serialization at the same module. The WO is to put them to separate ones.

@akurasov akurasov closed this as completed Aug 6, 2021
@ejektaflex
Copy link
Author

Are you referring to Gradle modules? If so, does this mean we must separate our project into two parts?
Say, a frontend module which uses Compose and a backend module that contains any other code, along with KSX?

@akurasov
Copy link
Contributor

akurasov commented Aug 9, 2021

@ejektaflex
yes, split into two parts. One with Compose and another with Serialization.

@akurasov
Copy link
Contributor

akurasov commented Aug 9, 2021

@ejektaflex please see nice example here- https://github.com/eymar/reproducing-issues/tree/compose-web-with-serialization

@EyeOfMidas
Copy link

Sorry for posting here; it's the first result that comes up when I search this error, but I got it from a completely different cause.

This line causes the error
suspend fun forEach(block: suspend (T) -> Unit) = processors.forEach(fun(t: T) { block(t) })

This line fixes it
suspend fun forEach(block: suspend (T) -> Unit) = processors.forEach{ block(it) }

This was with
kotlin version 1.5.21
kotlinx coroutine version1.5.1

@akurasov
Copy link
Contributor

@EyeOfMidas do you have the same issue in the plain Kotlin code? Do you have the same issue on Android?

@EyeOfMidas
Copy link

@EyeOfMidas do you have the same issue in the plain Kotlin code? Do you have the same issue on Android?

This is plain Kotlin code. We're writing a backend server using Ktor, so I don't have an Android development environment. You can reproduce it like this:

package example

class ExampleError<T> {
    suspend fun forEach(block: suspend (T) -> Unit) = listOf<T>().forEach(fun(it:T) { block(it) })
}

@akurasov
Copy link
Contributor

@EyeOfMidas
Then this is not the right place to report such issue. Here we work on Desktop/Web versions of Compose framework.

@akurasov
Copy link
Contributor

Looks like you are trying to use Compose along with Serialization. They couldn't be used in the same module. Try to move either of them to a separate one.

Newer versions of Compose would throw an error about it before compilation.

@akurasov akurasov self-assigned this Aug 18, 2021
@Iridescentangle
Copy link

@akurasov I'm facing the problem too but I'm not using kotlin-serialization, please help me...

e: org.jetbrains.kotlin.backend.common.BackendException: Backend Internal error: Exception during IR lowering
File being compiled: /Users/username/Documents/workspace/MyApp/app/src/main/java/com/a/b/c/d/e/ForwardActivity.kt
The root cause java.lang.AssertionError was thrown at: org.jetbrains.kotlin.backend.common.ir.IrUtilsKt.copyValueParametersToStatic(IrUtils.kt:264)
at org.jetbrains.kotlin.backend.common.CodegenUtil.reportBackendException(CodegenUtil.kt:239)
at org.jetbrains.kotlin.backend.common.CodegenUtil.reportBackendException$default(CodegenUtil.kt:235)
at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invokeSequential(performByIrFile.kt:68)
at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(performByIrFile.kt:55)
at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(performByIrFile.kt:41)
at org.jetbrains.kotlin.backend.common.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:96)
at org.jetbrains.kotlin.backend.common.phaser.CompositePhase.invoke(PhaseBuilders.kt:29)
at org.jetbrains.kotlin.backend.common.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:96)
at org.jetbrains.kotlin.backend.common.phaser.CompositePhase.invoke(PhaseBuilders.kt:22)
at org.jetbrains.kotlin.backend.common.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:96)
at org.jetbrains.kotlin.backend.common.phaser.CompilerPhaseKt.invokeToplevel(CompilerPhase.kt:43)
at org.jetbrains.kotlin.backend.jvm.JvmIrCodegenFactory.doGenerateFilesInternal(JvmIrCodegenFactory.kt:195)
at org.jetbrains.kotlin.backend.jvm.JvmIrCodegenFactory.generateModule(JvmIrCodegenFactory.kt:60)
at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.compileCorrectFiles(KotlinCodegenFacade.java:35)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.generate(KotlinToJVMBytecodeCompiler.kt:331)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli(KotlinToJVMBytecodeCompiler.kt:123)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli$default(KotlinToJVMBytecodeCompiler.kt:58)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:170)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:52)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:92)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:44)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:98)
at org.jetbrains.kotlin.incremental.IncrementalJvmCompilerRunner.runCompiler(IncrementalJvmCompilerRunner.kt:434)
at org.jetbrains.kotlin.incremental.IncrementalJvmCompilerRunner.runCompiler(IncrementalJvmCompilerRunner.kt:120)
at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compileIncrementally(IncrementalCompilerRunner.kt:357)
at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compileIncrementally$default(IncrementalCompilerRunner.kt:299)
at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compileImpl$rebuild

@jimgoog
Copy link
Collaborator

jimgoog commented Feb 12, 2022

@Iridescentangle Without a minimal repro, we probably wouldn't be able to make much progress understanding why you are running into an issue. Please post a minimal example project which demonstrates your issue.

@Iridescentangle
Copy link

@Iridescentangle Without a minimal repro, we probably wouldn't be able to make much progress understanding why you are running into an issue. Please post a minimal example project which demonstrates your issue.

I think it's difficult because I'm intergrating compose into current project , which means I bearly find the way to reproduce this problem😓 I doubt there is something wrong the way I intergrated ,so I tried several times these days in different branches, but got same result.
BTW,the file mentioned above,was reported during the compiler exception. I checked this class ,there is no kotlin-serialization included (even not depended by the project),and I tried to remove the coroutines-anko library,but also not helping.

@sandwwraith
Copy link
Member

If this problem is reproduced without kotlinx-serialization, please use Kotlin's issue tracker: https://youtrack.jetbrains.com/issues/KT

@jimgoog
Copy link
Collaborator

jimgoog commented Feb 22, 2022

I think it's difficult because I'm intergrating compose into current project , which means I bearly find the way to reproduce this problem😓

Typically, I start by reproducing the problem in my project, then start deleting as much stuff as I can until the problem goes away. If deleting something causes the problem to go away, I undo that change (so the problem comes back) and delete something else. Repeat this process until I'm left with the minimal amount of code necessary to reproduce the issue.

@Iridescentangle
Copy link

I think it's difficult because I'm intergrating compose into current project , which means I bearly find the way to reproduce this problem😓

Typically, I start by reproducing the problem in my project, then start deleting as much stuff as I can until the problem goes away. If deleting something causes the problem to go away, I undo that change (so the problem comes back) and delete something else. Repeat this process until I'm left with the minimal amount of code necessary to reproduce the issue.

Sounds well , maybe it would take me a long time to do this 😄 because my project is a hodgepodge

@Iridescentangle
Copy link

@jimgoog
Hello bro, finally I found these codes which causes this exception,although I have no idea with the exact reason.I tried to comment out the codes of the file and finally found out these codes.
The repo I used is a popup library XPopup

private var confirmPopup : ForwardConfirmPopup? = null

    private fun showForwardFavoriteConfirm(conversation:EMConversation?= null,group:EMGroup? = null,contact: UserDataBean?=null) {
        if(confirmPopup == null){
            confirmPopup = XPopup.Builder(this)
                    .setPopupCallback(object:SimpleCallback(){
                        override fun onCreated() {
                            showConfirmDetail(conversation,group,contact)
                        }
                    })
                    .asCustom(ForwardConfirmPopup(this){conversations,groups,contacts->
                        confirmPopup!!.dismiss()
                        showLoading()
                        viewModel.sendMessage(chooseType,conversations,groups,contacts)
                    })
                    .show() as ForwardConfirmPopup
        }else{
            showConfirmDetail(conversation,group,contact)
            confirmPopup!!.show()
        }

    }

@Iridescentangle
Copy link

@jimgoog I have no idea why it causes the exception,because it works well in the past.But if it became a problem ,I have to try other ways to solve this.So these codes look like this below

private fun showForwardFavoriteConfirm(conversation:EMConversation?= null,group:EMGroup? = null,contact: UserDataBean?=null) {

        if(confirmPopup == null){
            confirmPopup = ForwardConfirmPopup(this)
//            confirmPopup?.setOnForwardConfirmListener(object:OnForwardConfirmListener{
//                override fun onForwardConfirm(
//                    conversations: MutableSet<EMConversation?>,
//                    groups: MutableSet<EMGroup?>,
//                    contacts: MutableSet<UserDataBean?>
//                ) {
//                    confirmPopup!!.dismiss()
//                    showLoading()
//                    viewModel.sendMessage(chooseType,conversations,groups,contacts)
//                }
//            })
            confirmPopup = XPopup.Builder(this)
                    .setPopupCallback(object: SimpleCallback() {
                        override fun onCreated(popupView: BasePopupView?) {
                            super.onCreated(popupView)
                            showConfirmDetail(conversation,group,contact)
                        }
                    })
                    .asCustom(confirmPopup)
                    .show() as ForwardConfirmPopup
        }else{
            showConfirmDetail(conversation,group,contact)
            confirmPopup!!.show()
        }

    }

@praveenraikar
Copy link

I'm also facing the same issue & I'm not using any serialization plugin. Any help would be appreciated.
Thanks

MatkovIvan pushed a commit to MatkovIvan/compose-multiplatform that referenced this issue May 10, 2023
@okushnikov
Copy link

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler Compiler plugin related
Projects
None yet
Development

No branches or pull requests

10 participants