Is it possible to launch a debugger such as jdb from Maven? I have a pom.xml file that compiles the project successfully. However, the program hangs somewhere and I would really like to launch jdb or an equivalent debugger to see what's happening.
I compile using mvn compile and launch using:
mvn exec:java -Dexec.mainClass="com.mycompany.app.App"
I was expecting something like:
mvn exec:jdb -Dexec.mainClass="com.mycompany.app.App"
to launch the debugger but, as usual, my expectations are incongruent with maven's philosophy.
Also, I couldn't find any documentation (on Maven's website or google) to describe how debugging works. I suspect that I have to use some plugin.
If you are using Maven 2.0.8+, run the mvnDebug command in place of mvn and attach a debugger on port 8000.
For Maven <2.0.8, uncomment the following line in your %M2_HOME%/bin/mvn.bat (and maybe save the modified version as mvnDebug.bat):
#REM set MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
More details in MNG-2105 and Dealing with Eclipse-based IDE.
Just as Brian said, you can use remote debugging:
mvn exec:exec -Dexec.executable="java" -Dexec.args="-classpath %classpath -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044 com.mycompany.app.App"
Then in your eclipse, you can use remote debugging and attach the debugger to localhost:1044.
I thought I would expand on these answers for OSX and Linux folks (not that they need it):
I prefer to use mvnDebug too. But after OSX maverick destroyed my Java dev environment, I am starting from scratch and stubbled upon this post, and thought I would add to it.
$ mvnDebug vertx:runMod
-bash: mvnDebug: command not found
DOH! I have not set it up on this box after the new SSD drive and/or the reset of everything Java when I installed Maverick.
I use a package manager for OSX and Linux so I have no idea where mvn really lives.
(I know for brief periods of time.. thanks brew.. I like that I don't know this.)
Let's see:
$ which mvn
/usr/local/bin/mvn
There you are... you little b#stard.
Now where did you get installed to:
$ ls -l /usr/local/bin/mvn
lrwxr-xr-x 1 root wheel 39 Oct 31 13:00 /
/usr/local/bin/mvn -> /usr/local/Cellar/maven30/3.0.5/bin/mvn
Aha! So you got installed in /usr/local/Cellar/maven30/3.0.5/bin/mvn.
You cheeky little build tool. No doubt by homebrew...
Do you have your little buddy mvnDebug with you?
$ ls /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug
/usr/local/Cellar/maven30/3.0.5/bin/mvnDebug
Good. Good. Very good. All going as planned.
Now move that little b#stard where I can remember him more easily.
$ ln -s /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug /usr/local/bin/mvnDebug
ln: /usr/local/bin/mvnDebug: Permission denied
Darn you computer... You will submit to my will. Do you know who I am? I am SUDO! BOW!
$ sudo ln -s /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug /usr/local/bin/mvnDebug
Now I can use it from Eclipse (but why would I do that when I have IntelliJ!!!!)
$ mvnDebug vertx:runMod
Preparing to Execute Maven in Debug Mode
Listening for transport dt_socket at address: 8000
Internally mvnDebug uses this:
MAVEN_DEBUG_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE \
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000"
So you could modify it (I usually debug on port 9090).
This blog explains how to setup Eclipse remote debugging (shudder)
http://javarevisited.blogspot.com/2011/02/how-to-setup-remote-debugging-in.html
Ditto Netbeans
https://blogs.oracle.com/atishay/entry/use_netbeans_to_debug_a
Ditto IntelliJ
http://www.jetbrains.com/idea/webhelp/run-debug-configuration-remote.html
Here is some good docs on the -Xdebug command in general.
http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html
"-Xdebug enables debugging capabilities in the JVM which are used by the Java Virtual Machine Tools Interface (JVMTI). JVMTI is a low-level debugging interface used by debuggers and profiling tools. With it, you can inspect the state and control the execution of applications running in the JVM."
"The subset of JVMTI that is most typically used by profilers is always available. However, the functionality used by debuggers to be able to step through the code and set breakpoints has some overhead associated with it and is not always available. To enable this functionality you must use the -Xdebug option."
-Xrunjdwp:transport=dt_socket,server=y,suspend=n myApp
Check out the docs on -Xrunjdwp too. You can enable it only when a certain exception is thrown for example. You can start it up suspended or running. Anyway.. I digress.
I found an easy way to do this -
Just enter a command like this -
>mvn -Dtest=TestClassName#methodname -Dmaven.surefire.debug test
It will start listening to 5005 port. Now just create a remote debugging in Eclipse through Debug Configurations for localhost(any host) and port 5005.
Source - https://doc.nuxeo.com/display/CORG/How+to+Debug+a+Test+Run+with+Maven
If you are using Netbeans, there is a nice shortcut to this.
Just define a goal exec:java and add the property jpda.listen=maven
Tested on Netbeans 7.3
If you don't want to be IDE dependent and want to work directly with the command line, you can use 'jdb' (Java Debugger)
As mentioned by Samuel with small modification (set suspend=y instead of suspend=n, y means yes which suspends the program and not run it so you that can set breakpoints to debug it, if suspend=n means it may run the program to completion before you can even debug it)
On the directory which contains your pom.xml, execute:
mvn exec:exec -Dexec.executable="java" -Dexec.args="-classpath %classpath -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1044 com.mycompany.app.App"
Then, open up a new terminal and execute:
jdb -attach 1044
You can then use jdb to debug your program!=)
Sources:
Java jdb remote debugging command line tool
Why not use the JPDA and attach to the launched process from a separate debugger process ? You should be able to specify the appropriate options in Maven to launch your process with the debugging hooks enabled. This article has more information.
I use the MAVEN_OPTS option, and find it useful to set suspend to "suspend=y" as my exec:java programs tend to be small generators which are finished before I have manage to attach a debugger.... :) With suspend on it will wait for a debugger to attach before proceding.
I couldn't make any of the other solutions work and then I tried starting maven with the following.
mvn exec:exec -Dexec.executable="java" -Dexec.args="-classpath %classpath -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000 com.example.Main"
This worked for me and then I searched some more and found this other answer. IntelliJ can run Maven project in debug mode but ignores breakpoints
The fact is that my application is a spring-boot application. Now, the link referred to above may be right and the problem is that the spring-boot plugin creates a new fork that somehow invalidates the interaction between debugger and target app. I'm saying this because I got some info on how this may work from here
In any case, I don't know how the two solutions are related to each other. Is the first solution also preventing spring-boot from creating a fork??
Sadly I have no clue at the moment.
Here is how I do it.
For example:
mvn clean azure-functions:run -DenableDebug
Then, after it starts up, you'll see a link in the Terminal that says "Attach Debugger".
To me, that is the easiest way to do it.
Related
Sometimes I have to deal with an improperly configured Eclipse installation and when I try to run it only the dialog "Java was started but returned exit code shows up without giving me any useful information to trace the actual reason Java failed to start.
What is the best approach to debug this kind of problem?
There are several command-line options that can help with troubleshooting. I'd start with -debug -consoleLog and see if that produces useful output.
You can run eclipse with the verbose attribute from command line
eclipse -verbose
Read more about debugging eclipse and plugins here http://exploreeclipse.blogspot.nl/2014/01/enable-eclipse-verbose-for-trouble.html?m=1
By default, eclipse launches with javaw.exe process, since it's a window thread so you will not be able to see any verbose messages.
Step 1: Add below VM parameter in eclipse.ini file. By default, eclipse will have javaw.exe, modify it to java.exe
-vm
C:/KK/jdk1.6.0_32/bin/java.exe
Step 2: Pass verbose parameter during the eclipse launch.
eclipse -verbose
I have a tomcat running after making configuration and when I type jdb in terminal it says initializing. So I like to know
How to attach jdb with tomcat and specify servlet name.
What is the compile option (like in C its eg. -g with gdb) to include debugging symbols when compiling servlet with javac
I have opt/tomcat/apache-tomcat-10.0.10 so I guess Tomcat version is 10
The javac command switch to add all debugging symbols is ... -g. Line numbers and source file names are actually added by default, you only gain information on local variables (see this question).
You can not connect a debugger to a running JVM, unless it was started with the appropriate command line option (see this question).
Tomcat has a helper script bin/catalina.sh that can help you start it with the correct parameters:
catalina.sh jpda start starts Tomcat in the background with debugging enabled. You can connect to it with:
jdb -attach localhost:8000
catalina.sh jpda run works as in the previous case, but in the foreground,
catalina.sh debug starts Tomcat through jdb. You just need to use run to start it.
Once you are connected you can use:
stop in <class id>.<method>
to add break points.
Remark: Both javac and jdb are not often used these days. Most people use tools like Ant, Maven, Gradle, etc. to compile their projects and IDEs to debug the code.
I'm trying to run a java program on windows in VSCODE. When I click the run button at the top it opens the Java Process Console and runs the following command:
$ cmd /C "c:\Users\user\.vscode\extensions\vscjava.vscode-java-debug-0.31.0\scripts\launcher.bat "C:\Program Files\AdoptOpenJDK\jdk-11.0.10.9-hotspot\bin\java.exe" -Dfile.encoding=UTF-8 #C:\Users\jbree\AppData\Local\Temp\cp_7gau2431e54dxprosf092viw9.argfile com.example.restservice.RestServiceApplication "
It then prints out: Command 'cmd' not found, but there are 16 similar ones., and I'm not too sure what to do afterwards.
I just ran into this exact issue! After some debugging, I found out it's because my terminal (in VS Code) was running off of WSL.
Make sure to check which terminal you're using! If you're trying to run Java locally, then you can configure a default shell ie. bash.
Let me know if this helps.
Edit: I also found this, not sure if it will help, but here you go!
https://stackoverflow.com/a/58058378/11060097
your java debugger is using wsl. and most likely your java is installed on windows. not linux on windows. to fix this for me, i changed the settings for java debugging to use the external console. settings->java debugger->externalTerminal . this will then use the "external windows" setting for vscode. which should use cmd.exe (the windows shell, no linux).
This error happens because you probably have wsl has your standard terminal but it's probably configured to launch cmd using a windows path.
WSL won't understand what that windows path is, so you need to change it using a path structure it can understand
So
hit Ctrl+, to hit the Settings screen
type in terminal to see all the terminal settings
You will see an option called Terminal> External:Windows Exec
Change C:\Windows\System32\cmd.exe to /mnt/c/Windows/System32/cmd.exe
I had this error too and came here initially but I managed to figure out it was an incompatible path issue that was the cause.
Does anyone know how to make eclipse or netbeans use the graphics card in optimus laptops by invoking optirun (bumblebee) inside the IDE so that one can just use the run button in the IDE to run the program in a graphics card within the IDE.
In simplest form I just want the IDE to do the equivalent of optirun ./javaproject
The way I did this in Eclipse was to first start the Java debugger jdwp and listen to a port. Then start the JVM with optirun java ... and use jdwp to connect to this port. Both tasks can be started at the same time in Eclipse by creating a Launch Group in the debug configuration settings (Run -> Debug Configurations). In detail:
Create a Remote Java Application debug configuration with "Standard (Socket Listen)" Connection Type and some arbitrary port, e.g. 56789. This attaches the Java debugger jdwp on port 56789 to a virtual machine which accepts debug connections at this port.
Now we need to start a JVM with optirun. This can be done with a External Tool Configuration (Run -> External Tools -> External Tool Configurations). Create a new Program configuration in the left side of the External Tools Configurations window. You could directly start optirun java <additional arguments> by filling in the required fields. However, I have decided to use a shell script which is reusable by different projects (As can be seen below, there is one part missing to make it entirely reusable. I'm glad for any help from more experienced Eclipse users...). Hence, the Location field points to this shell script. The script itself accepts three arguments: the classpath for the project, the name of the Java executable, and the port number. These arguments can be passed to the script in the Arguments field of the Main tab, e.g.
${project_classpath:${selected_resource_name}}
ExecName
56789
The shell script looks like this, assuming optirun is in your PATH:
#!/bin/sh
CLASS_PATH=${1}
JAVA_EXECUTABLE=${2}
PORT=${3}
# TODO: fix this java library path: pass it as an argument as well. Is there an Eclipse variable which stores this?
JAVA_LIBRARY_PATH=/usr/local/share/OpenCV/java
#------------------------------------------------------------------------------
optirun ${JAVA_BIN} -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:${PORT} -Djava.library.path=${JAVA_LIBRARY_PATH} -Dfile.encoding=UTF-8 -classpath ${CLASS_PATH} ${JAVA_EXECUTABLE}
#------------------------------------------------------------------------------
Finally, the two pieces are brought together in a Launch Group in the Debug Configurations window (Run -> Debug Configurations). Create a new Launch Group and add the two previously generated Debug configurations by clicking on Add in the Launches tab and by selecting the appropriate configurations.
Note that due to the classpath variable in step 2 (i.e. ${project_classpath:${selected_resource_name}}), the appropriate package needs to be selected in the Package Explorer before clicking on the run debug configuration button (make sure that the Launch Group is selected).
This solution works perfectly for me: I can debug Java code inside Eclipse which calls native code involving CUDA optimizations and Bumblebee only activates the discrete graphics card when necessary.
Just use optirun to start the IDE. For example, optirun eclipse or optirun netbeans
I build the project in Netbeans (F11) and run the following in a terminal:
optirun java -jar path/to/javaproject/dist/javaproject.jar
Mind that if you have any java parameters in your project, you need to add it manually. My workflow is like this:
Locate the Java options from the project, open Project -> Properties, Run. At VM Options I see -Djava.library.path=lwjgl/native/windows;:lwjgl/native/linux. I also have some parameters that I want to pass to main(String[]). With this information, I open a terminal and run:
cd path/to/javaproject
optirun java -Djava.library.path=lwjgl/native/windows;:lwjgl/native/linux \
-jar dist/javaproject.jar some paremeters
Another hint, if you have to open and close the program frequently, run optirun bash in a different tab so that preparing the use of the graphics card becomes faster. Alternatively, you can run optirun netbeans, but that means that the nvidia card will always be on even if you are programming which increases power use and increase the heat.
Important: if you are using a 32-bit JVM or Java libraries on a 64-bit machine, you also need to install the 32-bit drivers and libraries. For Ubuntu, the nvidia package already contains 32-bit drivers, see this answer. For other distros, you likely need to install lib32-* packages for Mesa, VirtualGL and nvidia-utils.
You can also rename java to java_real and use this portion of code as your java command :
#!/bin/bash
path=$(dirname $(readlink -f $0))
args=""
runner="$path/java_real"
for var in "$#"
do
if [ "$var" = "-3d" ]; then
runner="primusrun $runner"
else
args="$args $var"
fi
done
$runner $args
NOTE : I had to do this in /usr/lib/jvm/java-7-openjdk-amd64/jre/bin, not in /usr/bin to make it work with Eclipse.
In Eclipse, just add "-3d" in your program arguments and you're good to go !
I know there's some JAVA_OPTS to set to remotely debug a Java program.
What are they and what do they mean ?
Before Java 5.0, use -Xdebug and -Xrunjdwp arguments. These options will still work in later versions, but it will run in interpreted mode instead of JIT, which will be slower.
From Java 5.0, it is better to use the -agentlib:jdwp single option:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1044
Options on -Xrunjdwp or agentlib:jdwp arguments are :
transport=dt_socket : means the way used to connect to JVM (socket is a good choice, it can be used to debug a distant computer)
address=8000 : TCP/IP port exposed, to connect from the debugger,
suspend=y : if 'y', tell the JVM to wait until debugger is attached to begin execution, otherwise (if 'n'), starts execution right away.
I have this article bookmarked on setting this up for Java 5 and below.
Basically run it with:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044
For Java 5 and above, run it with:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1044
If you want Java to wait for you to connect before executing the application, replace suspend=n with suspend=y.
Since Java 9.0 JDWP supports only local connections by default.
http://www.oracle.com/technetwork/java/javase/9-notes-3745703.html#JDK-8041435
For remote debugging one should run program with *: in address:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000
For java 1.5 or greater:
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 <YourAppName>
For java 1.4:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 <YourAppName>
For java 1.3:
java -Xnoagent -Djava.compiler=NONE -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 <YourAppName>
Here is output from a simple program:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044 HelloWhirled
Listening for transport dt_socket at address: 1044
Hello whirled
java
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8001,suspend=y -jar target/cxf-boot-simple-0.0.1-SNAPSHOT.jar
address specifies the port at which it will allow to debug
Maven
**Debug Spring Boot app with Maven:
mvn spring-boot:run -Drun.jvmArguments=**"-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8001"
Command Line
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=PORT_NUMBER
Gradle
gradle bootrun --debug-jvm
Maven
mvn spring-boot:run -Drun.jvmArguments="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=PORT_NUMBER
Here is the easiest solution.
There are a lot of environment special configurations needed if you are using Maven. So, if you start your program from maven, just run the mvnDebug command instead of mvn, it will take care of starting your app with remote debugging configurated. Now you can just attach a debugger on port 8000.
It'll take care of all the environment problems for you.
-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=PORT_NUMBER
Here we just use a Socket Attaching Connector, which is enabled by default when the dt_socket transport is configured and the VM is running in the server debugging mode.
For more details u can refer to : https://stackify.com/java-remote-debugging/
If you are using java 9 or higher, to remotely debug (which is also the case when you use docker at local) you have to provide --debug *:($port). Because from java 9 --debug ($port) will only allow to debug at local, not remotely.
So, you can provide command in docker-compose like
command: -- /opt/jboss/wildfly/bin/standalone.sh --debug *:8787