microsoft / microsoft/java-debug

[WSL] Breakpoints fail to bind when attaching to JVM in WSL2 after Debugger for Java 0.58.3 update; rollback fixes

Open
#611 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

ai-triaged bug
Dominant language
Java
Stars
409
Forks
204
Avg merge
1d 13h
Merged PRs (30d)
4

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:

  1. 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
  1. In Windows Cursor/VS Code, attach to 127.0.0.1:5005 (port forwarded via Remote - WSL).
  2. Set a breakpoint in any controller method.
  3. Send an HTTP request hitting that controller.
  4. Observe: request hangs but IDE never shows breakpoint. Meanwhile, jdb attach 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=*:5005 can't be used with Java 8 due to gethostbyname errors.
  • 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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the WSL2 scenario with the provided JDWP command, Windows VS Code or Cursor, and a controller breakpoint, then compare Debugger for Java 0.58.3 with 0.58.2. Investigate the java-debug attach and breakpoint behavior using the existing repository entry points. Done means breakpoints resume correctly in WSL2 while native Windows behavior remains unaffected.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, spring-boot, vscode
Domain
devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.