Debugger Java application
To sum up some experiences on Java debug, Java developers generally debug Java programs through IDE, such as Eclipse. After being started in debug mode, you can add breakpoints to any line, when the program runs on this line, it will be blocked by the breakpoint. As we all know, Java programs run as bytecode in class files. JVM is responsible for interpreting bytecode into JVM Internal commands.
Specification documents, even manually translate the meaning of each bytecode, just like the ancient Assembly commands, 0 ~ 255 each byte represents a single command. Different commands require different numbers of parameters, so as to read the appropriate number of bytecode in sequence and translate the code into real machine commands.
In fact, in addition to the bytecode corresponding to the program compiled by the programmer, the class file also contains a large amount of debugging information, which is used to record the code corresponding to each JVM command, the declaration position of each variable, and the line number in the source code corresponding to each function call and numerical calculation ...... All of these debugging information can be used by JVM to provide feedback during runtime and respond to breakpoint and debugging operations.
Therefore, if there is no special compilation command to process the debugging information, there is no obfuscator to confuse the debugging information, even if only the class file is obtained, you can also decompile or debug it during runtime. Dynamic debugging can use any editor, IDE, or JDK tool that developers prefer.
The reason why JVM accepts a series of commands issued by dynamic debugging is that the JVM itself has a complete debug framework. When a Java program runs in the JVM, as long as the debug switch is enabled, the JVM debugging framework can correctly and instantly feedback Debugging commands. (Completely independent from source code)
JVM debug framework specification: http://download.oracle.com/javase/1.3/docs/guide/jpda/index.html
JVM provides three Protocols to support runtime debugging:
L
Jvmdi: Java Virtual Machine debug Interface
L
Jdwp: Java debug wire protocol
L
Jdi: Java debug Interface
To enable the debug switch of JVM, some startup parameters need to be added. A typical example is:
-Xdebug-xrunjdwp: Transport = dt_socket, Server = Y, address = 8000
Official explanation: Listen for a socket connection on port 8000. suspend this VM before Main class loads (suspend = y by default). Once the debugger
Application connects, it can send a jdwp command to resume the VM.
For more parameter descriptions, see the official documentation: http://download.oracle.com/javase/1.3/docs/guide/jpda/conninv.html
As for the tools used for debugging, I tested eclipse and intellij IDE.
And JDK's built-in debugger tool: jdb
When using a large ide such as eclipse or intellij IDE, you can add a new remote
Java application, set the host and port to start debugging. You can associate the application and source code on the interface so that the breakpoint can better feedback to the source code.
When using jdb, It is not shown to be so powerful through command line interaction. However, it is highly recommended to be used as an exercise to understand the principles. Enter the jdk_home/bin directory and enter jdb to run. Generally, you can connect the host and port to the local or remote JVM with the debug switch enabled. For example:
Jdb-Attach 192.168.1.101: 8000
Sometimes I encounter some Java programs that do not have the main method and use JNI to locally call the driver. At this time, it seems that jdb cannot be connected with the attach parameter, therefore, another connection method is used:
Jdb-connect com. Sun. jdi. socketattach: Hostname = 192.168.1.101, Port = 8000
This is because jdb connects to JVM mainly through two methods: Shared Memory and sockets. There are no details about the two methods for researchers at the moment, so I will share it with you later! Sorry ~~ :)