microsoft / microsoft/vscode-java-debug
Cannot debug JDK17 itself with "Debugger for Java" v0.49.1
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 591
- Forks
- 429
- Ø Merge
- 1 T. 9 Std.
- Gemergte PRs (30 T.)
- 19
Beschreibung
I'm building and debugging OpenJDK 17 on Windows 11. I'd like to debug it with VSCode.
I submitted the issue #1285 before for other version of extensions, but now Java Debugger extension seems totally broken.
- I have disabled "build before launch" for both User and Workspace, but every time I run the debug configuration (see below), I see the message about "Debug 'Launch Java Program': compiling..." and then "Build failed, do you want to continue?" with a lot of compilation errors.
- It can debug source of my tests, but it cannot step in JDK classes. It seems like it cannot find neither source files, not debug info for fresh built fast-debug JDK.
- If I open one of JDK java-files in VSCode and try run the debugger (the same configuration), it shows "Debug 'Launch Java Program': compiling...", and may hang until OutOfMemory error occurs.
- I have set "java.configuration.runtimes" option to manually downloaded JDK, but, in TaskMonitor, I still see Java.exe process running from "C:\Users\username\.vscode\extensions\redhat.java-1.17.0-win32-x64\jre\17.0.6-win32-x86_64\bin". It looks like scanning my JDK source files, but cannot do this properly. It consumes a lot of memory (1GB+), and reports about OutOfMemory error in VSCode time to time.
Is it really broken now?
Is my configuration wrong maybe?
Environment
- Operating System: Windows 11
- JDK version: 17
- Visual Studio Code version: 1.77.3
- Extension Pack for Java: v0.25.10
- Debugger for Java: v0.49.1
- Language Support for Java(TM) by Red Hat: v1.17.0
My setting.json:
"java.configuration.runtimes": [
{
"default": true,
"name": "JavaSE-17",
"path": "c:\\Users\\username\\work\\jdk"
}
]
"java.debug.settings.onBuildFailureProceed": false,
"java.debug.settings.forceBuildBeforeLaunch": false
My launch.json:
{
"type": "java",
"name": "Launch Java Program",
"request": "launch",
"cwd": "${workspaceFolder}\\jdk\\myjdk\\MyJdkTest\\MyJdkTest",
"mainClass": "jdk.test.lib.myjdk.MyJdkTest",
"vmArgs": "-ea <other vm args>",
"args": "<java test args>",
"classPaths": [
"${workspaceFolder}\\classes\\jdk\\myjdk\\MyJdkTest\\MyJdkTest.d",
"${workspaceFolder}\\classes\\test\\lib"
],
"javaExec": "c:/Users/username/work/myjdk/build/windows-x86_64-server-fastdebug/jdk/bin/java.exe",
},
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginne damit, das Verhalten mit den bereitgestellten settings.json und launch.json zu reproduzieren, und verwende dabei die aufgeführten Versionen von OpenJDK 17, VS Code und der Erweiterung unter Windows 11. Überprüfe die konfigurierte Runtime, das Verhalten von build-before-launch, das schrittweise Ausführen von JDK-Quellcode und die Speichernutzung des Java-Prozesses; abgeschlossen ist die Untersuchung, wenn der Fehler isoliert und entweder eine funktionierende Debugging-Konfiguration oder ein konkreter Fehler der Erweiterung identifiziert wurde.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- java
- Bereich
- devtools
- Issue-Typ
- Bug
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Muss geklärt werden
- Anfängerfreundlichkeit
- 35/100