[WSL] Breakpoints fail to bind when attaching to JVM in WSL2 after Debugger for Java 0.58.3 update; rollback fixes #611
Description
Environment:
- Host OS: Windows 11, IDE: Cursor/VS Code
- Guest: WSL2 Ubuntu 22.04
- Java: OpenJDK 1.8.0_432 (Java 8)
- Extensions: Debugger for Java 0.58.3 (latest), Language Support for Java 1.47.0
- Spring Boot app running inside WSL2, debugged via JDWP attach on port 5005.
Expected:
Attaching from Windows (Cursor/VS Code) to a JDWP-enabled JVM in WSL2 stops at breakpoints in my project code.
Actual:
After updating to Debugger for Java 0.58.3 and Language Support for Java 1.47.0, attach no longer stops at breakpoints. HTTP requests hang as if the breakpoint is hit, but the IDE never jumps to the code. Attaching using jdb and setting the same breakpoints works fine, so JDWP and class debug info are good.
Rolling both extensions back (Debugger for Java 0.58.2 and Language Support for Java 1.46.0) restores proper behaviour.
Repro steps:
- Build and run the Spring Boot jar in WSL2 with JDWP:
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 \
-Dspring.profiles.active=local -Duser.timezone=UTC \
-jar build/libs/your-app.jar
- In Windows Cursor/VS Code, attach to 127.0.0.1:5005 (port forwarded via Remote - WSL).
- Set a breakpoint in any controller method.
- Send an HTTP request hitting that controller.
- Observe: request hangs but IDE never shows breakpoint. Meanwhile,
jdbattach shows that the breakpoint is hit.
Notes:
- This only occurs when the JVM runs in WSL2 and the IDE is on Windows. A colleague running everything natively on Windows (no WSL) doesn't see the problem.
address=*:5005can't be used with Java 8 due togethostbynameerrors.- This seems like a regression introduced in 0.58.3 (or 0.58.3 + language server update). Rolling back fixes the issue.
Thanks for looking into this.
Activity
github-actions commentedon Nov 14, 2025
Hi Clerton Sampaio (@clertonbruno), I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.
Suggestions:
• Use source mapping so the debugger can bind breakpoints to files under WSL2. In your launch.json
attachconfiguration add something like:{ "type": "java", "request": "attach", "hostName": "127.0.0.1", "port": 5005, "sourcePaths": [ { "remoteRoot": "/home/your-user/your-project", "localRoot": "${workspaceFolder}" } ], "trace": "verbose" }– See Remote debug docs: https://code.visualstudio.com/docs/java/java-debugging#_configure-the-remote-debug-settings
• Enable verbose logging to capture why breakpoints don’t bind:
– Add
"trace": "verbose"and inspect the DEBUG CONSOLE for messages about class loading and breakpoint mapping.• As a temporary workaround, rollback to Debugger for Java 0.58.2 & Language Support for Java 1.46.0.
• If this persists, please file an issue including the verbose logs.
High-confidence references:
• Breakpoints not working after recent update (similar symptom of ignored breakpoints) — microsoft/vscode-java-debug#1364
Other references with low confidence
• Breakpoints not working at all in 0.58.x series — microsoft/vscode-java-debug#1531
• Spring/WSL2 debug lands in platform classes, not user code — microsoft/vscode-java-debug#795
The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!
wenytang-ms commentedon Apr 28, 2026
Clerton Sampaio (@clertonbruno) Thanks for the report. The symptom suggests the breakpoint may actually be hit and the debuggee thread is suspended, but the client
fails to resolve/show the source for the stopped stack frame.
Could you help collect a bit more information?
Please try this version matrix:
Please share your full
launch.jsonattach configuration, especiallyhostName,port,projectName, andsourcePaths.Please share the relevant paths:
Please enable
"trace": "verbose"and attach the Java Debug logs from session start until the request hangs. The most usefulparts are
setBreakpoints,stopped, andstackTraceresponses, especially thesource.pathvalues.When the request hangs, does the Call Stack view show a stopped thread, Unknown Source, or nothing at all?
This will help us determine whether the regression is in the debug adapter or in JDT-LS/Eclipse source lookup/path mapping under WSL.
wenytang-ms commentedon Oct 29, 2026
I tried to reproduce this using a minimal Spring Boot application, but could not reproduce the reported behavior.
Test environment:
For both a regular controller call and a call containing lambda frames, breakpoints bound and were hit, VS Code navigated to the correct source file and line, and stackTrace requests completed successfully. After continuing execution, the HTTP requests returned 200. These results only cover this minimal setup; they do not establish that the originally reported problem has been fixed.
Closing this for now because I could not reproduce it with the available information. If you can reproduce it again, please provide enough details or logs for us to investigate, ideally:
"java.debug.logLevel": "verbose"in settings.json. Please redact any sensitive information before sharing logs.We can reopen this issue and investigate further once sufficient reproduction information or diagnostic logs are available.