Repository navigation
Java remote attach to debug not hitting breakpoints. #755
Description
Activity
Anyone could help me out with this issue?
JK.Ryan (@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?
The repository was private. Is there any other data I could provide to help me out with this issue?
JK.Ryan (@jkryanchou), could you share the command line arguments to launch your remote service?
Jinbo Wang (@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?
To debug a remote Java program, it has two steps:
Step 1: Start the application in debugging modejava -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?
Jinbo Wang (@testforstephen) Here are the agentlib commandline args:
java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=nIn 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.Jinbo Wang (@testforstephen) OK, Thanks a lot. I will try it later. If any other issue exists . I would reply on this issue.
Jinbo Wang (@testforstephen) I have changed the
suspend=yargs. 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.I'm also having a similar issue
16 remaining items
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.
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.
Having the same problem. None of the solutions mentioned above worked.
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.
Brian Heise (@bnheise) Tarek (@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.
Brian Heise (@bnheise) Tarek (@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.
Jinbo Wang (@testforstephen) it's going to be very hard to provide such details. But as soon as I'm able I'll let you know.
I'm swamped at work now, but I'll see if I can't put together a minimal example later this week.
While I'm getting an example together, I will provide some additional context.
- We are connecting remotely to a springboot application running inside a docker container
- 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)
- Our launch.json:
{ "type": "java", "name": "Debug (Attach)", "request": "attach", "hostName": "localhost", "port": 5005, }- We are able to connect to the debug server successfully
- We are able to pause the execution, and once we do so we can view variables, step in, step out, step foreward, etc
- We are able to set breakpoints, but it does not pause when we pass a breakpoint
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.
Brian Heise (@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.
Jinbo Wang (@testforstephen) Thanks for the clarification. It is definitely some kind of bug then, because the code does match and the breakpoint is set correctly.
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.jsonfor 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
bashso you may need to adjust this. For example, I'm not sure ifbashneeds 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: 5005is output to the console.Attach Debugger
A launch configuration called
Remote connectis defined in the locallaunch.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 2If 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.2I 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!
I found a workaround:
- Put a breakpoint at the method declaration.
- Put a breakpoint inside the method.
The breakpoint will hit inside the method (not at the declaration).
I don't know, but it works!
Reacted by Jordan HendricksonReacted by Jordan Hendrickson
[provide a description of the issue]
Environment
Steps To Reproduce
[step 1] Set remote debug configuration
[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