Has anybody played around (and had issues) with `-Xdebug` in kotlin 1.8? I've been getting `java.lan...

# coroutines

[daphillips]

Has anybody played around (and had issues) with -Xdebug in kotlin 1.8? I've been getting java.lang.VerifyError: Bad local variable type errors whenever I turn it on in my project.

I haven't been able to create a minimal reproducible example yet, but it seems to happen around scope.launch or channel.send calls...

[ephemient]

the verifier should tell you which class and method failed, right? if you dump the bytecode it might have a hint as to what went wrong

[daphillips]

That's a good point. I've looked at bit at what the verifier mentions, but haven't gotten to the bytecode level yet. That's probably a good thing to look into

[daphillips]

Blindly poking around at the code though leads to the very interesting discovery that it always seems to be Type top (current frame, locals[5]) is not assignable to reference type , but at different locations depending on how I manipulate the stack. With the peculiar part being that it's always the 5th-indexed local variable...

more to investigate

[Norbi]

I've just run into the same error 😞

java.lang.VerifyError: Bad local variable type
Exception Details:
  Location:
    ...-W5ldpIw(Ljava/lang/String;Lkotlin/jvm/functions/Function1;Lkotlin/coroutines/Continuation;)Ljava/lang/Object; @707: iload
  Reason:
    Type 'java/util/concurrent/locks/Lock' (current frame, locals[9]) is not assignable to integer

Without -Xdebug the error goes away...

[daphillips]

@Norbi I was able to get a minimal reproducible example. I'm still uncertain as to what the cause is, but I at least have enough now to submit a bug report

[daphillips]

for the curious, this was the smallest I was able to make it:

fun main() = runBlocking {
    Path("/tmp")

    withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
        println("hello world!")
    }
}

[ephemient]

huh. that's interesting, it's failing in the code generated for the very first state, I can't tell why it's producing that load though

[ephemient]

definitely worth filing a YouTrack issue over this

[daphillips]

The really interesting part is replacing Path() with Paths.get() seems to fix the issue? So I wonder if it's something related to how kotlin inlines Path() to target platforms? ¯\_(ツ)_/¯

[ephemient]

experimenting with the definition of <http://kotlin.io|kotlin.io>.path.Path, this generates OK bytecode:

inline fun Path(path: String): Path = Paths.get(path)

while this generates broken bytecode:

@Suppress("INVISIBLE_REFERENCE", "INVISIBLE_MEMBER")
@kotlin.internal.InlineOnly
inline fun Path(path: String): Path = Paths.get(path)

when used in the above reproducer

[ephemient]

minimized the example more:

import kotlin.coroutines.*

@Suppress("INVISIBLE_REFERENCE", "INVISIBLE_MEMBER")
@kotlin.internal.InlineOnly
inline fun f(a: Int): Int = a

fun main() {
    suspend {
        f(0)
        suspendCoroutine<Unit> {}
    }
}

[daphillips]

Interesting find. I'll make sure to add it in my ticket writeup