kotlin-debug-adapter icon indicating copy to clipboard operation
kotlin-debug-adapter copied to clipboard

Published 20 hours ago • verified publisher icon fwcd

Can't debug simple KotlinQuickStart project

Open mattflix opened this issue 5 years ago • 16 comments

Hello,

Thanks for your work on this extension! I am excited to use it. However, I am unable even to get the default KotlinQuickStart project to debug.

The project does successfully build and run from the VS Code terminal:

joesmac:KotlinQuickStart joeblow$ ./gradlew run

> Task :run
Hello world

BUILD SUCCESSFUL in 0s
3 actionable tasks: 2 executed, 1 up-to-date

Great, so then I set up the following .settings/launch.json (under the same project folder):

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "kotlin",
            "request": "launch",
            "name": "Kotlin Launch",
            "projectRoot": "${workspaceFolder}",
            "mainClass": "MainKt"
        }
    ]
}

I am not using a multi-project workspace. This is just a basic single-folder VS Code project (basically just a clone of the KotlinQuickStart sample project).

Btw, I have used VS Code to debug other languages, and am familiar with usage.

Anyway, when I attempt launch the above debug configuration, I always get the following output in the Debug Console:

[INFO] main      Connected to client
[INFO] async1    Successfully resolved Gradle dependencies
[INFO] async1    Starting JVM debug session with main class MainKt
[ERROR] async1    Internal error: com.sun.jdi.connect.VMStartException: VM initialization failed
for: /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java -classpath /Users/
joeblow/.gradle/caches/modules-2/files-2.1/org.jetbrains/annotations/13.0/
919f0dfe192fb4e063e7dacadee7f8bb9a2672a9/annotations-13.0.jar:/Users/joeblow/.gradle/caches/
modules-2/files-2.1/org.jetbrains.kotlin/kotlin-compiler-embeddable/1.3.11/
a8db6c14f8b8ed74aa11b8379f961587b639c571/kotlin-compiler-embeddable-1.3.11.jar:/Users/joeblow/
.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.3.11/
aae7b33412715e9ed441934c4ffaad1bb80e9d36/kotlin-reflect-1.3.11.jar:/Users/joeblow/.gradle/caches/
modules-2/files-2.1/org.jetbrains.kotlin/kotlin-script-runtime/1.3.11/
1ef3a816aeacb9cd051b3ed37e2abf88910f1503/kotlin-script-runtime-1.3.11.jar:/Users/joeblow/.gradle/
caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-scripting-compiler-embeddable/1.3.11/
d7d145f70c063e3bb2edb41b766971e359155b99/kotlin-scripting-compiler-embeddable-1.3.11.jar:/Users/
joeblow/.gradle/caches/modules-2/files-2.1/junit/junit/4.12/
2973d150c0dc1fefe998f834810d68f278ea58ec/junit-4.12.jar:/Users/joeblow/.gradle/caches/modules-2/
files-2.1/org.hamcrest/hamcrest-core/1.3/42a25dc3219429f0e5d060061f71acb49bf010a0/
hamcrest-core-1.3.jar:/Users/joeblow/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/
kotlin-stdlib/1.3.11/4cbc5922a54376018307a731162ccaf3ef851a39/kotlin-stdlib-1.3.11.jar:/Users/
joeblow/Desktop/HelloKotlin/build/classes/kotlin/main -Xdebug -Xrunjdwp:transport=dt_socket,
address=nfml-joeblowKYG:49412,suspend=y MainKt

Any idea what's wrong?

Software:

  • macOS High Sierra: 10.13.6
  • VS Code: 1.32.2
  • (VS Code extension) Kotlin Debugger: 0.2.2
  • (VS Code extension) Kotlin: 0.1.13

Java:

openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

mattflix avatar Mar 14 '19 02:03 mattflix

Did you run ./gradlew build before launching the debugger (as described in README.md)?

fwcd avatar Mar 18 '19 12:03 fwcd

Yes, running either ./gradlew run (which, as shown, proves the build works and the app runs) or ./gradlew build before attempting to debug makes no difference. Both run or build complete without errors.

But, when attempting to debug, VC Code just shows an "Internal Error" dialog along with the previously quoted error output.

mattflix avatar Mar 18 '19 16:03 mattflix

I am able to run the quickstart app with the same launch.json as above and it runs to completion. The only difference is a patch version increment in VS Code and different OS. Maybe some plugin conflict is involved? Here are my specs:

Software:

  • Windows 10 Pro 1809 (17763.379)
  • VS Code: 1.32.3 (user setup)

The following relevant plugins are installed

  • Debugger for Java: 0.17.0
  • Gradle Language Support: 0.2.3
  • Kotlin: 0.1.13
  • Kotlin Debugger: 0.2.2
  • Language Support for Java(TM) by Red Hat

However when I set a breakpoint on the println line then run I get a VS popup when the breakpoint would be hit saying

Unable to open 'MainKt': File not found
(file:///path-to-repository-root/src/main/kotlin/MainKt)

The path-to-repository does not contain anything fancy (spaces, accents, etc).

bachratyg avatar Mar 21 '19 15:03 bachratyg

Fwiw, in the meantime, my VS Code has also updated itself to 1.32.3 (like @bachratyg), but this has made no difference. @bachratyg is also running on Windows, while I am running on Mac.

Btw, I have added my Java version information above.

mattflix avatar Mar 21 '19 17:03 mattflix

I'm running against an older Oracle JDK:

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

Bud does not seem to matter. I'm able to run with OpenJDK 11.0.2 just fine.

bachratyg avatar Mar 22 '19 08:03 bachratyg

Okay, something's changed...

I was just giving Kotlin debugging another try tonight and when I opened my project (same one this issue has been about) and pressed F5, VS Code briefly flashed some notification about LLVM being updated (I think). The notification only appeared once and I can't quite remember what it said.

But... now the debugger no longer gives the Debug Console error message that I showed previously. In fact, the debugger actually seems to have started up and is doing debugging things.

However, there is now another issue.... The debugger doesn't seem to be able to find any source files. For example, although the debugger seems to be stopped somewhere in the main() function right after I press F5, VS Code shows a warning popup in the bottom right corner that says:

Unable to open 'MainKt': File not found
(file:///Users/joeblow/Desktop/Projects/HelloKotlin/src/main/kotlin/MainKt).

Note that the main file is named Main.kt, not MainKt, which would probably explain why VS Code can't find the file.

If I create a bogus file named at the path shown in the warning, the warning goes away, and debugger opens that (bogus) file and shows the current execution line there (which is not very useful, but shows that it really is the file the debugger thinks it is looking for).

Interestingly, the Stack Trace window in VS Code shows the app stopped in a file correctly named Main.kt.

So... seems like some kind of source location information or mapping has gone wrong somewhere?

mattflix avatar Mar 31 '19 07:03 mattflix

More information...

The Unable to open 'MainKt': File not found error (that I mention above) only occurs if I have a breakpoint set in Main.kt.

The error appears to occur because the debugger is trying to bring up the source file corresponding to the breakpoint that has been hit, but cannot find it (since it appears to be looking for the wrong name, as I describe in my previous comment).

If the breakpoint is removed, the debuggee (in this case, KotlinQuickStart) does run without error under the debugger -- but of course also without taking advantage of the debugger.

Interestingly, this problem only seems to affect breakpoints in Main.kt. If I define another "normal" class in another file, say in Foo.kt, create an instance and call it from Main.kt, the debugger can successfully hit, display, and step through code at breakpoints set in Foo.kt.

So, only a problem with the special "main" class?

mattflix avatar Apr 01 '19 08:04 mattflix

Even more information...

Suddenly, the debugger started giving the original Internal error: com.sun.jdi.connect.VMStartException error again. I was very confused and couldn't figure out what was different... until I did.

I have seemingly found a cause... my network status.

If I turn my VPN off while connected to the network, the debugger will reliably start up via F5 (though it still has the issue where it cannot find the Main.kt file if a breakpoint is set there).

But, if I either turn my VPN on while connected to the network, or simply disconnect from any network (e.g. disable wifi), the debugger will reliably encounter the aforementioned internal error when attempting to start via F5.

So... apparently, debugging with this extension has some kind of hard dependency on network access that is affected by whether a VPN is active and/or the network is connected?

mattflix avatar Apr 02 '19 05:04 mattflix

Thank you for providing such a detailed description of the issue!

For usual launches, no network access should be required. The naming resolution is probably an issue with top-level Kotlin classes that somehow do not get mapped correctly back to file names. I will investigate this soon.

fwcd avatar Apr 02 '19 13:04 fwcd

I'm having the same issue (v0.2.2). I can run ./gradlew build and ./gradlew run just fine, but after doing so, the debugger fails to run.

[INFO] main      Connected to client
[INFO] async1    Successfully resolved Gradle dependencies
[INFO] async1    Starting JVM debug session with main class MainKt
[ERROR] async1    Internal error: com.sun.jdi.connect.VMStartException: VM initialization failed for:
/Users/username/.asdf/installs/java/openjdk-11.0.1/bin/java -classpath /Users/username/.gradle/caches/modules-2/files-2.1/org.jetbrains/annotations/13.0/919f0dfe192fb4e063e7dacadee7f8bb9a2672a9/annotations-13.0.jar:
/Users/username/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-compiler-embeddable/1.3.11/a8db6c14f8b8ed74aa11b8379f961587b639c571/kotlin-compiler-embeddable-1.3.11.jar:
/Users/username/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.3.11/aae7b33412715e9ed441934c4ffaad1bb80e9d36/kotlin-reflect-1.3.11.jar:
/Users/username/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-script-runtime/1.3.11/1ef3a816aeacb9cd051b3ed37e2abf88910f1503/kotlin-script-runtime-1.3.11.jar:
/Users/username/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-scripting-compiler-embeddable/1.3.11/d7d145f70c063e3bb2edb41b766971e359155b99/kotlin-scripting-compiler-embeddable-1.3.11.jar:
/Users/username/.gradle/caches/modules-2/files-2.1/junit/junit/4.12/2973d150c0dc1fefe998f834810d68f278ea58ec/junit-4.12.jar:
/Users/username/.gradle/caches/modules-2/files-2.1/org.hamcrest/hamcrest-core/1.3/42a25dc3219429f0e5d060061f71acb49bf010a0/hamcrest-core-1.3.jar:
/Users/username/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.3.11/4cbc5922a54376018307a731162ccaf3ef851a39/kotlin-stdlib-1.3.11.jar:
/Users/username/code/KotlinQuickStart/build/classes/kotlin/main -Xdebug -Xrunjdwp:
transport=dt_socket,address=hermes:63756,suspend=y MainKt

Java:

gopenjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)

launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "kotlin",
      "request": "launch",
      "name": "Kotlin Launch",
      "projectRoot": "${workspaceFolder}",
      "mainClass": "MainKt"
    }
  ]
}

lee-reinhardt avatar Jun 25 '19 06:06 lee-reinhardt

Having the same issue (just started to look into it) and if I run the command (see below) manually outside of VSCode I get:

ERROR: transport error 202: gethostbyname: unknown host ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]

this is leading me to think networking issue from this part of the command address=Roberts-MacBook-Pro.local:53791 which is not a resolvable name on my machine. Is there a config to change that to be localhost or is that encoded in the plugin?

The command which is being run:

/Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre/bin/java -classpath /Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains/annotations/13.0/919f0dfe192fb4e063e7dacadee7f8bb9a2672a9/annotations-13.0.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-compiler-embeddable/1.3.21/677cc9553b8964c895abc76da9b6a0faea8f671d/kotlin-compiler-embeddable-1.3.21.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.3.21/d0d5ff2ac2ebd8a42697af41e20fc225a23c5d3b/kotlin-reflect-1.3.21.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-script-runtime/1.3.21/29363d474ee6fda354900636320a177c7286def9/kotlin-script-runtime-1.3.21.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains.intellij.deps/trove4j/1.0.20181211/216c2e14b070f334479d800987affe4054cd563f/trove4j-1.0.20181211.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-scripting-compiler-embeddable/1.3.21/510f640ddab3074a890450f870e65630cf5e0055/kotlin-scripting-compiler-embeddable-1.3.21.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-test-junit/1.3.21/17d1a5cdd282f901004dea50a04ba363b4a9ccef/kotlin-test-junit-1.3.21.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-test/1.3.21/38d09017c4e62144d76281b35e9b1c17c22ef056/kotlin-test-1.3.21.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-test-common/1.3.21/36470631bd1b5d7d78506e4dcb644e1b0d1708a8/kotlin-test-common-1.3.21.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-test-annotations-common/1.3.21/fa06fbbfdd3ac286f91c2a320f67bcb3e1ff45ee/kotlin-test-annotations-common-1.3.21.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/junit/junit/4.12/2973d150c0dc1fefe998f834810d68f278ea58ec/junit-4.12.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.hamcrest/hamcrest-core/1.3/42a25dc3219429f0e5d060061f71acb49bf010a0/hamcrest-core-1.3.jar:/Users/rmaclean/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk8/1.3.21/d0634d54452abc421db494ad32dd215e6591c49f/kotlin-stdlib-jdk8-1.3.21.jar:/Users/rmaclean/Desktop/scratch/test/build/classes/kotlin/main -Xdebug -Xrunjdwp:transport=dt_socket,address=Roberts-MacBook-Pro.local:53791,suspend=y test.AppKt

rmaclean-ee avatar Aug 01 '19 07:08 rmaclean-ee

I had this same problem, your point about the host name in address not being resolvable was happening for me, so I just added that to hosts file (pointing to 127.0.0.1) which fixed things for me

ahimberg avatar Dec 25 '20 22:12 ahimberg

I have been having the same problems, and after finding this thread I started investigating network connections. It seems to work if I work from home over WiFi with VPN enabled, or if I'm at the office with WiFi, or if I'm completely without network connection. But If I'm at the office with cable connection, it does not work. My understanding of network things is very limited, so I didn't dig any deeper than that.

My java version does not seem to matter so much; I get the same result using OpenJDK 14.0.1 as I do with Open JDK 1.8.0_275. I'm on MacOS 11.1.

I tried @ahimberg's solution, and it worked for me too. Here is what I did in more detail (in case someone else wants to to try):

  1. Look carefully at the first [ERROR] message in the DEBUG console in VSCode. In my case it starts like this: ERROR] async1 Internal error: com.sun.jdi.connect.VMStartException: VM initialization failed for: /Library/Java/JavaVirtualMachines/adoptopenjdk-14-openj9.jdk/Conten... and goes on for a long time, mostly listing jar-files. At the end OF THE FIRST ROW in this message (it is line-broken several times), the network name of the machine is printed: dt_socket,address=BLABLABLA.gu.gu.se:59491.
  2. Open the file /etc/hosts in a text editor and add the following line: 127.0.0.1 BLABLABLA.gu.gu.se where you replace 'BLABLABLA.gu.gu.se' with the name in your error message.
  3. Save the hosts file and try debugging again.

MagnusMG avatar Jan 18 '21 13:01 MagnusMG

I came here because I am having the same phenomenon. I cannot step-debug my Kotlin test cases. Everything is smooth in a Java vscode I can step debug individual test case because there is a clickable element for each test case to start step debugging.

I can prove that the test cases got executed because if I add assertTrue(false); then vscode will detect it during debug run. But I cannot step-debug the test cases which is the essence of the vscode debugger = step debug.

So far, I can step debug my main entry point. But I want to step debug my test cases. What is the solution?

typelogic avatar Jan 25 '21 10:01 typelogic

Similar problem when I am trying to launch:

RROR: transport error 202: connect failed: Connection refused
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]

Java version:

openjdk version "1.8.0_282"
OpenJDK Runtime Environment (build 1.8.0_282-b08)
Eclipse OpenJ9 VM (build openj9-0.24.0, JRE 1.8.0 Mac OS X amd64-64-Bit Compressed References 20210120_839 (JIT enabled, AOT enabled)
OpenJ9   - 345e1b09e
OMR      - 741e94ea8
JCL      - ab07c6a8fd based on jdk8u282-b08)

dapx avatar Feb 21 '21 15:02 dapx

i have the same issue. I'm on Ubuntu 20.04 and when i try debugging (after a $gradle build) the debug console says: [ERROR] async1 Internal error: com.sun.jdi.connect.VMStartException: VM initialization failed for: /usr/lib/jvm/java-11-openjdk-amd64/bin/java -classpath /home/user/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.3.72/8032138f12c0180bc4e51fe139d4c52b46db6109/kotlin-stdlib-1.3.72.jar -Xdebug -Xrunjdwp:transport=dt_socket,address=user:48547,suspend=y -m src/kot i tried the proposed fix where you add 127.0.0.1 user to the etc/hosts file but when i try to debug again it simply change the port and give the same error.

mbarbaro09 avatar Mar 05 '21 18:03 mbarbaro09