Java remote attach to debug not hitting breakpoints.

[jkryanchou]

[provide a description of the issue]

Environment

• Operating System: MacOSX Mojave 10.14.6
• JDK version: 1.8.0_121
• Visual Studio Code version: 1.14.1
• Java extension version: 0.8.1
• Java Debugger extension version: 0.24.0

Steps To Reproduce

1. [step 1] Set remote debug configuration

    {
           "type": "java",
           "name": "Debug (Attach) - Remote",
           "request": "attach",
           "hostName": "192.168.1.1",
           "timeout": 30000,
           "port": 8000,
           "projectName": "service"
       },
   

2. [step 2] Run and Debug remote, and it shows that warning message, and not hitting the breakpoints set below.

   [Warn - 11:25:04 AM] 2020-2-3 11:25:04 [Warn] The debugger and the debuggee are running in different versions of JVMs. You could see wrong source mapping results.
   Debugger JVM version: 1.8.0_121
   Debuggee JVM version: 1.8.0_102

[attach a sample project reproducing the error]
attach logs

Current Result

Not hitting the breakpoints.

Expected Result

Hit the breakpoints and could view the variables.

Additional Informations

I used the IDEA remote attach through the commands, and it works without problem. I wonder if any differences between IDEA and VSCode-java-debug remote attach commands?

• IDEA Remote debug options
  

• VSCode Java Debug remote attach configuration

[jkryanchou]

Anyone could help me out with this issue?

[akaroml]

@jkryanchou, thanks for reaching out.

The remote capability of VS Code is different from remote debugging in IntelliJ. We would love to help but we are not able to reproduce the issue based on the materials provided in this thread.

Could you please share the project with us?

[jkryanchou]

The repository was private. Is there any other data I could provide to help me out with this issue?

[testforstephen]

@jkryanchou, could you share the command line arguments to launch your remote service?

[jkryanchou]

@testforstephen How could I print out the command line arguments which to launch the remote service In VSCode? Or you mean the launch.json configuration?

[testforstephen]

To debug a remote Java program, it has two steps:
Step 1: Start the application in debugging mode

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=<debug-port> -cp <ClassPath> <ClassName>

Step 2: Configuration launch.json to attach to the application.

Currently if you're using attach debugging in VS Code, you must manually launch your service at first. Could you tell me the approach to launch your service?

[jkryanchou]

@testforstephen Here are the agentlib commandline args:

java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n

[testforstephen]

In the args, suspend=n, this means your application is started not in suspend mode. The application will start execution immediately, and no need to wait for a debugger to connect it. This is why you don't see hitting breakpoints, because your program may have executed the breakpoint code before the debugger ready.

To solve your program, you need set suspend=y, then the JVM starts in suspended mode and stays suspended until a debugger attaches to it.

[jkryanchou]

@testforstephen OK, Thanks a lot. I will try it later. If any other issue exists . I would reply on this issue.

[jkryanchou]

@testforstephen I have changed the suspend=y args. while it works as before and still couldn't hit the breakpoint. I guess it was something wrong with my network to the remote java agent.

[lherman-cs]

I'm also having a similar issue

[akaroml]

@testforstephen can you reproduce this? if no, then we need some help from @jkryanchou or @lherman-cs to reproduce it.

[jkryanchou]

@akaroml OK, I will post it later.

[omcfig]

this worked for me:
MacOS/VSCode Insiders/OpenJDK8/Skaffold: $ skaffold debug --port-forward
terminal reports back debug port:Picked up JAVA_TOOL_OPTIONS: -agentlib:jdwp=transport=dt_socket,server=y,address=5005,suspend=n,quiet=y
VSCode: Add debug Configuration: Java: Attach to Remote Program

[alturium]

I'm having the same issue and would like to get the java debugger working for vs code. Currently, I am able to remote debug using IntelliJ.

The breakpoints are not hit and display as "Unverified Breakpoint" in source code.

Created launch.json at project name directory.
Program (Apache Tomcat) is running on a vagrant vm (VirtualBox). Successfully debugged using IntelliJ.

Operating System: MacOSX Catalina
JDK version: 1.8.0_252 (adoptopenjdk)
Visual Studio Code version: 1.46
Java extension version: 0.9.1
Java Debugger extension version: 0.26.0

Command line arguments:
-agentlib:jdwp=transport=dt_socket,address=192.168.100.112:8000,server=y,suspend=n

Running debugger attaches to remote process.

[testforstephen]

The breakpoints are not hit and display as "Unverified Breakpoint" in source code.

This explained the reason. Looks like your source code is not loaded correctly by vscode-java. @alturium Could you share a sample code for reproduce?

[omcfig]

@alturium - What is the contents of your launch.json?

[alturium]

@omcfig launch.json configuration:
"configurations": [
{
"type": "java",
"name": "Debug (Attach) - Remote",
"request": "attach",
"hostName": "192.168.100.112",
"port": 8000
},
I have tried adding sourcePaths (relative or absolute? top-level directory or target directory?), and projectName. To no avail.

Since debugging works for intellij, I'm going to take a guess that the the issue is loading and mapping the source code. It would imply that the debuggee process has the instrumented debugging information.

Configuration: Build a maven project (pom.xml). Output to target directory. Project directory has:
pom.xml
src/main/java/org/...
target/...

Process is apache running JSP servlet engine. There is a .war file. When I do a binary dump of the classes, I notice that the source is 'org/...'.

Is there a use of sourcePaths to help the debugger map the source code to the debugged process?

@testforstephen It will take some time to put together an example project. Has the java debugger been tested with remote apache debugging environment?

Thank you for the help! Unless there is a an undocumented feature, or perhaps a way to use sourcePaths parameter, I'm afraid that this will take some effort to diagnose and may be a bug against the vscode-java-debug.

[raphaelluchini]

I have the same problem. It does not attach to the remote application. I'm running with docker. On IntelliJ works fine!
MacOX Catalina
VSCode 1.48.2
Application Java 1.8
Java Debugger: 0.28.0
Java extension version: 0.10.0

I wonder if is not the difference of Java versions between VSCode and the Application.

[testforstephen]

@raphaelluchini What error did you see when it does not attach to the remote application?

[raphaelluchini]

@testforstephen No Errors, just hanging, the timeout also seems it's not working, I set to 1000 ms and the debugger keeps trying to connect until I try many times to stop.

[fdambrosio]

I have the same problem too, it's occurring after a fresh update of windows and vscode. Before that it was working fine.

[fdambrosio]

I've resolved my issue with 'clean the Javalanguage server workspace' option on VsCode

[no-response]

This issue has been closed automatically because it needs more information and has not had recent activity. Please reach out if you have or find the answers we need so that we can investigate further.

[JamesIves]

I've resolved my issue with 'clean the Javalanguage server workspace' option on VsCode

I had this exact same problem, and this was the resolution for me too.

[tarekahf]

I am facing similar problem but with jar file in the class path and the source code in another place outside the main project. See below for details:

https://stackoverflow.com/q/75304937/4180447

Any help would be greatly appreciated.

[bnheise]

Having the same problem. None of the solutions mentioned above worked.

[tarekahf]

The teams are in process to switch over to vscode but when I presented them with this issue they were shocked! Now they are considering staying in Eclipse.

[testforstephen]

@bnheise @tarekahf To help us investigate the problem further, please create a new issue and describe how to reproduce it in detail. It would also be very helpful if you could share a sample project that demonstrates the issue. You can make a similar project with the same structure if your original one is private.

[tarekahf]

@bnheise @tarekahf To help us investigate the problem further, please create a new issue and describe how to reproduce it in detail. It would also be very helpful if you could share a sample project that demonstrates the issue. You can make a similar project with the same structure if your original one is private.

@testforstephen it's going to be very hard to provide such details. But as soon as I'm able I'll let you know.

[bnheise]

I'm swamped at work now, but I'll see if I can't put together a minimal example later this week.

[bnheise]

While I'm getting an example together, I will provide some additional context.

1. We are connecting remotely to a springboot application running inside a docker container
2. We are configuring the JVM's debug server using GRADLE_OPT environment variable (GRADLE_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:5005)
3. Our launch.json:

{
      "type": "java",
      "name": "Debug (Attach)",
      "request": "attach",
      "hostName": "localhost",
      "port": 5005,
    }

4. We are able to connect to the debug server successfully
5. We are able to pause the execution, and once we do so we can view variables, step in, step out, step foreward, etc
6. We are able to set breakpoints, but it does not pause when we pass a breakpoint

[bnheise]

One hypothesis: the version of java in the Docker container is java 21. The version of java running configured on JAVA_HOME in the host system is Java8, although Java21 is installed. Is it possible that this could be the cause? If so, is it possible to configure which version of Java the debug console is using? For the sake of other project dependencies in the system, the system JAVA_HOME needs to remain Java8.

[testforstephen]

@bnheise The JDK version does not affect the debugging of your own application code, only the JDK code itself. One factor that could affect the breakpoint is whether the source code version matches the class running in the debuggee JVM. If your local source code differs from the remote one, or if you see an "Unverified Breakpoint" hint on the breakpoint line, the breakpoint is probably not set well.

[bnheise]

@testforstephen Thanks for the clarification. It is definitely some kind of bug then, because the code does match and the breakpoint is set correctly.

[bnheise]

Hi guys. I have a minimum example. I was able to reproduce the problem without using Docker at all. You can find the repository here.

Steps to reproduce.

Clone Repo

gh repo clone bnheise/java-debugger-breakpoint-failure

Adjust Settings.json

I included my settings.json for the project to illustrate my local settings. You may need to adjust to match your local environment. Probably the location of your Java-21 sdk is in a different location than mine so please adjust as necessary.

{
  "java.configuration.runtimes": [
     {
      "name": "JavaSE-21",
      "path": "~/.local/share/rtx/installs/java/zulu-javafx-21.30.15"
     }
  ],
  "java.import.gradle.java.home": "~/.local/share/rtx/installs/java/zulu-javafx-21.30.15",
  "java.compile.nullAnalysis.mode": "automatic",
}

Set GRADLE_OPTS For Debugging

Note that the exact command below is not tested. I don't use bash so you may need to adjust this. For example, I'm not sure if bash needs the environment variable based as a string or not. Please confirm the proper way to set an environment variable using whatever terminal you use.

export GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:5005"

Apply Breakpoints

Open the file src/main/java/com/example/demo/HelloController.java. It looks as follows:

package com.example.demo;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {

  @GetMapping("/")
  public String index() {
    System.out.println("TEST DEBUG");
    System.out.println("TEST DEBUG 2");
    return "Greetings from Spring Boot!";
  }

}

On Line 11, you'll see System.out.println("TEST DEBUG");. Apply a breakpoint here. If breakpoints are working correctly, then we will expect to see TEST DEBUG output to the console, but not TEST DEBUG 2.

Start the Application

./gradlew bootRun

As the application boots, confirm that Listening for transport dt_socket at address: 5005 is output to the console.

Attach Debugger

A launch configuration called Remote connect is defined in the local launch.json. Using vscode's debug console, launch the remote debugger.

Confirm that the debugger has connected (you should see the stepper menu appear at the top center of the vscode window.

Trigger the HelloController Endpoint

Open http://localhost:8080.

Observe the console output:

TEST DEBUG
TEST DEBUG 2

If you check the debugger in vscode, you will also see that the debugger has not been triggered: the screen has not jumped to the location of the breakpoint, and the stepper options have not been activated.

System Details

OS: macOS Sonoma 14.1.2
VsCode: 1.85.1
Debugger for Java (vscode plugin): v0.55.0
JDK: zulu-javafx-21.30.15
Gradle Version: 8.5
Springboot Version: 3.2

[antonio-petricca]

I have a Weblogic project which I debug with no problems under IntelliJ.

With VSCode I am able to break into Jersery controller methods, but not into EJB bean methods!

[antonio-petricca]

I found a workaround:

1. Put a breakpoint at the method declaration.
2. Put a breakpoint inside the method.

The breakpoint will hit inside the method (not at the declaration).

I don't know, but it works!