IssueTracker

Alon, can you try to reproduce this? Could it be there is a expression evaluation taking a long time to finish (or maybe stuck in an infinite loop?)

Raising priority assuming the use case is common.

I can repro on HEAD

Updating with some early findings.

In KotlinClassRenderer there is a function:

    private fun List<Method>.getters() =
        filter { method ->
            !method.isAbstract &&
            GetterDescriptor.GETTER_PREFIXES.any { method.name().startsWith(it) } &&
            method.argumentTypeNames().isEmpty() &&
            method.name() != "getClass" &&
            !method.name().endsWith("\$annotations") &&
            method.declaringType().isInKotlinSources() &&
            !method.isSimpleGetter() &&
            !method.isLateinitVariableGetter()
        }
        .distinctBy { it.name() }
        .toList()

That throws when called with the methods of ComposeView.

Specifically, it throws when method.isSimpleGetter() or method.isLateinitVariableGetter() are called on one particular method: getShouldCreateCompositionOnAttachedToWindow.

It turns out that this method is actually contained twice in the methods of ComposeView:

0 = {ConcreteMethodImpl@87945} "androidx.compose.ui.platform.ComposeView.getShouldCreateCompositionOnAttachedToWindow()"
1 = {ConcreteMethodImpl@87972} "androidx.compose.ui.platform.AbstractComposeView.getShouldCreateCompositionOnAttachedToWindow()"

And org.jetbrains.kotlin.idea.debugger.isSimpleStaticVariableGetter throws on the seond one. The one from AbstractComposeView

OK

So, to check if a method is a Simple Static Variable Getter, this is called:

private fun Method.isSimpleStaticVariableGetter() =
    verifyMethod(4, intArrayOf(Opcodes.GETSTATIC))

This first checks that the bytecode has the expected size and if not, it does some more extensive checks that require getting the constant pool.

And it throws when it discovers that it can't get the constant pool because the vm has a new capability which doesn't support it.

  public boolean canGetConstantPool() {
    this.validateVM();
    return this.hasNewCapabilities() && this.capabilitiesNew().canGetConstantPool;
  }

I can repro with a trivial class:

private class BadGetter {
    val f: Boolean
        get() = true
}

Note that this only happens on Android code. The same trivial class in an Kotlin JVM project works so I suspect the issue is with DEX/ART not supporting getting of the constant pool?

I'm not sure what the proper fix is. It's easy enough bypass the issue by making method.isSimpleGetter() and isLateinitVariableGetter() return false if they can't resolve themselves because canGetConstantPool is false but perhaps there's another way to test for this condition that doesn't depend on the constant pool.

I filed https://youtrack.jetbrains.com/issue/KTIJ-23671/Some-Objects-Cannot-Be-Displayed-By-Debugger-on-Android

I think this needs to be fixed by a JetBrains engineer, or perhaps the Denmark team.

Assigning to Mads.

Looks like this code is inspecting bytecode. Therefore, it is expecting Java bytecode, but what we have is dex code. So, the debugger should bail out of this when not on JVM (when it does not have the constant pool capability). Can you look at whether we can do something safe at first to not hang and have fallback behavior that is less good?

The real fix (which is on my backlog of things to maybe do at some point) is to abstract the bytecode inspecting parts of the debugger, have an interface for what we need to be able to do, and implement that for both Java bytecode and for Dex bytecode. That is non-trivial as getting the dex bytecode in a form where we have everything we need is non-trivial.

My fix https://github.com/JetBrains/intellij-community/pull/2237 was approved.

Is this something we would want to CP? It seems to me to be a pretty common occurrence given what I know about the issue.

Yes, we should CP...

Wrt to the fix, I am surprised we check for DEX as opposed to check for the absence/presence of the Constant Pool. I thought there was a specific API to do this, and I thought we already had to make a similar fix a while back for Android (feel free to ignore this paragraph if I am not understanding correctly, this is just vague recollection of things)

Well, I wrote the code hat bypasses if the VM is DEX. I think it's more correct to check for DEX because the lack of a CP is just a side effect. Even if the CP was available, the bytecode check would be invalid because the bytecode would be quite different than expected anyway.

Binary part of the fix was completed in ag/20672780 and verified.

The issue is back (2023.1.1 Canary 7). Reproduction steps are the same as before.

I can't repro on 2023.1.1 Canary 7. See screenshot.

Is it happening on the same item in the debug window as before? ComposeView?

Sorry, my mistake, the repro steps are a little different. Open Evaluate window enter view and Evaluate. For the first time there will be an error and all variables in Variables window are Collecting data.... From that moment, the debugger is broken and does not work (breakpoints do not work as well). When I tap on Evaluate for the second time there is Evaluating... only.

This is a totaly different issue.

org.jetbrains.kotlin.backend.common.CompilationException : Back-end: Please report this problem https://kotl.in/issue
/home/aalbert/src/MyApplication/app/src/main/java/com/example/myapplication/MainActivity.kt:-1:-1
Details: Internal error in file lowering: kotlin.UninitializedPropertyAccessException: lateinit property parent has not been initialized

As the error messages suggests, this is a JetBrains Kotlin issue and should be reported at https://kotl.in/issue. However, it's already been reported and even has a workaround:

As a workaround, you can set a Registry option debugger.kotlin.evaluator.use.jvm.ir.backend=false

I confirmed the workaround works. See screenshot.

It works, thank you.

Is this still an issue ? as i just migrated from Flamingo to Giraffe and debugger seems broken , not able to run test in debugging mode at all

Comments #20 #21, please note that this bug was identified as a specific issue related to the ComposeView class.

The bug was fixed and closed.

It sounds like you are experiencing similar symptoms but it's likely a different cause.

Please file a new bug and attach screenshots, ode snippets and log files so we can better understand the issue.