Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the method of IntelliJ IDEA remote debugging". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what is the method of IntelliJ IDEA remote debugging"?

Debugging skills of practical IDEA

If you are a Java developer, I believe you have heard of IntelliJ IDEA. Like most Java developers, I also used Eclipse to develop at the beginning, but since I changed IDEA, I can no longer live without it and become a loyal fan of IDEA (sorry, do a wave of advertising.) ).

I have to say, JetBrains, a software company from Czechoslovakia, is really an enterprise of conscience, and its products are all high-quality products, except IDEA, WebStorm,PhpStorm,PyCharm, etc., the style is very similar, and some similar shortcuts including debugging skills are also universal.

Open the debug panel of IDEA, as shown in the following figure, which can be roughly divided into five parts:

Single-step tracking

Breakpoint management

Evaluation expression

Stack and thread

Variable observation

1.1 single-step tracking

When it comes to debugging, it is estimated that many people's first reaction is to track and analyze the program step by step. In fact, IDEA provides many keyboard shortcuts to help us track the program. You can probably list the following tips:

Show Execution Point

Debugging often need to browse the code, analysis of the code, sometimes after browsing several source files can not find where the current implementation, many people may use Navigate Back to return, although you can also go back, but may need to point back button multiple times, it is relatively easy to use this technique to quickly locate the current debugger is executing the line of code.

Step Over

This is the most basic single-step command, each time one line of code is executed, and if there is a way to skip it, it can be said that it is really one step at a time.

Step In / Force Step In

Step Over skips the execution of the method and can observe the return value of the method, but if you need to enter the method and observe the execution details of the method, you need to use the Step In command. In addition, the Step In command skips the system methods that come with jdk, and you need to use the Force Step In command if you want to track the execution details of the system methods.

For which system methods to ignore when stepping, you can configure them in the IDEA configuration items Settings-> Build, Execution, Deployment-> Debugger-> Stepping, as shown in the following figure.

Step Out

When you use the Step In command to trace to the inside of a method, if you find that you don't want to continue calling the method, you can just finish executing the method and stop at the next line where the method is called. This is the Step Out command.

Drop to Frame

This move can be said to be a big killer of the debugger. In single-step debugging, if you overstep due to carelessness and do not see the execution of the key code, such as trying to locate the value of an intermediate variable, if only you can go back to that line of key code and execute it again, Drop to Frame provides us with the ability to go back to the place where the method was called (unlike Step Out, Step Out goes back to the next line of the method call) Let's debug this method again, but don't be careless this time.

The principle of Drop to frame is actually very simple. As the name implies, it deletes the top stack frame of the stack (that is, the method currently being executed) and returns the program to the previous stack frame (parent method). It is conceivable that this will only restore the local variables in the stack, and the global variables cannot be recovered. if there is a place in the method to operate on the global variables, there is no way to do it again.

Run to Cursor / Force Run to Cursor

These two commands are very useful when you need temporary breakpoints, for example, you already know which line of code you want to analyze, but you don't need to make a lot of unnecessary breakpoints. You can use this command to execute to a line directly, and Force Run to Cursor can even ignore all breakpoints and go straight to where we want to analyze.

1.2 breakpoint management

Breakpoints are one of the basic functions of the debugger, which allows the program to pause where it is needed to help us analyze the running process of the program. In IDEA breakpoint management, as shown in the following figure, the reasonable use of breakpoint techniques can quickly make the program stop where we want to stop:

Breakpoints can be divided into two types: line breakpoints are paused on a particular line of code, while global breakpoints are stopped when a condition is met, and are not limited to a fixed line, such as pausing the program when an exception occurs.

1.2.1 Line breakpoint

Suspend (All / Thread)

Condition

Conditional breakpoint. This should also be a skill that every developer using the debugger should master. When you encounter traversing large List or Map objects, such as 1000 Person objects, you cannot tune every object once. You may only want to break the breakpoint when person.name = 'Zhangsan', and you can use conditional breakpoints, as shown in the following figure:

Log message to console

Evaluate and log

Some people may be surprised when they see the Suspend option above. Isn't my next breakpoint just to stop the program? Why do you need this option? Isn't that a little superfluous? Don't you want the program to stop at the next breakpoint?

Before I discovered the Evaluate and log technique, I was surprised by this, too, until one day I suddenly found that the combination of Suspend Off and Evaluate and log was really useful. As mentioned earlier, don't use System.out.println as a debugging tool, because you can use this technique to print all the information you want to print without modifying your source code.

Remove once hit

One-time breakpoint. The Run to Cursor described above is an example of an one-time breakpoint.

Instance filters

Class filters

Pass count

I don't use a lot of these, but they should also be very useful skills that I can write down first. In IDEA, each object has an instance ID,Instance filters that is used when the instance of the code at the breakpoint and sets the ID match to be broken. Pass count pauses when the breakpoint is executed for several times.

1.2.2 Global breakpoint

Exception breakpoints

Method breakpoints

Field watchpoints

Personally, I feel that none of these skills are very commonly used. Students who are interested should try it on their own.

1.3 Evaluation expression

Next to a bunch of step-by-step buttons, there is an inconspicuous button, which is called an evaluation expression. It is useful when debugging, you can view the value of a variable, you can evaluate the value of an expression, and you can even calculate the value of your own piece of code, which corresponds to the following two different modes:

Expression pattern (Expression Mode)

Snippet mode (Code Fragment Mode)

These two modes are similar to Expression View and Display View in Eclipse. You can also write a piece of code to execute in Display View, which is really powerful, but it should be noted that you can only write code snippets here, not custom methods, as shown in the following figure:

1.4 stacks and threads

There is nothing to say about this, one view can see all the current threads, and the other view can see the current function stack. Thread dump can be done in the thread view to analyze what each thread is currently doing; in the stack view, you can switch stack frames, combined with the variable observation area on the right, you can easily view the local variables and parameters in each function.

Thread view

Stack view

1.5 variable observation

The variable area and the observation area can be merged or displayed separately (as shown in the following figure). I prefer to display them separately, so that local variables, parameters, and static variables are displayed in the variable area, and the expression to be observed is displayed in the observation area.

The observation area is similar to the Expression mode in the evaluation expression, you can add the expression you need to observe, and you can see the value of the expression in real time while debugging. The content of the variable area is relatively fixed, and the value will be different as the stack frame on the left is adjusted. You can also modify the original value of the variable here.

Debug using jdb command line

I believe many people have heard of gdb, which can be said to be the ancestor of the debugging world. In the past, I used it to debug programs when I was learning Cpicard +. Like gdb, jdb is a command-line version of the debugger for debugging Java programs. And jdb doesn't need to be installed and downloaded, it's a tool that comes with JDK (not in the bin directory of JDK, but not in JRE). More ways to play IDEA: IntelliJ IDEA content aggregation

Every time I study a new technology, I always see if there is a command-line version of the tool that can be replaced. Operating under the command line gives people a sense of solidity. Every instruction, every parameter, is clearly there. Compared with the graphical interface tools, you can learn deeper knowledge, instead of hiding the technical details behind the graphical interface, you can find every parameter under the command line. Each configuration is a point that can be learned.

2.1 jdb basic commands

Debug the Java program in jdb as shown in the figure below, just use the jdb Test command to load the program.

After running the jdb Test command, the program does not run at this time, but stops there waiting for further commands. At this point, we can figure out where to make the next breakpoint, such as at the main () function, and then use the run command to run the program:

> stop in Test.main is delaying breakpoint Test.main. Will be set after the class is loaded. > run running Test setting uncaptured java.lang.Throwable setting delayed uncaptured java.lang.Throwable > VM started: setting a delayed breakpoint: Test.main

You can see that the program has not started running before the run command is executed, and the breakpoint is called "deferred breakpoint". When the program is actually running, that is, when JVM starts, the breakpoint is set. In addition to the stop in Class.Method command, breakpoints can also be set using stop at Class:LineNumber.

Main [1] stop at Test:25

Breakpoints in jdb, there are not so many tricks in IDEA, what conditions breakpoints, what Instance filters do not support, can only obediently step by step. At the breakpoint, you can use the list command to view the code near the breakpoint, or you can use the step command to step through, print or dump to print the value of the variable or expression, the locals command to view all variables in the current method, and the cont command to continue executing the code.

There are some other commands that are not covered in detail. You can use help to view a list of all commands, or refer to the official documentation of jdb. More ways to play IDEA: IntelliJ IDEA content aggregation

2.2 explore the class file structure

When debugging Java programs in jdb, it is possible that the source code files and class files are not together, so you need to specify the source code location:

# jdb-sourcepath path/to/source Test

If you do not specify the source location, you will be prompted that the source file cannot be found when you use the list command. If there is no source file, it will be a complete nonsense in jdb. We know that when the Java code is executed, it runs in the JVM in the form of bytecode. We can guess that there must be some information associated with the source code in the class file, similar to the obj file in the Cmax Candle + language. Otherwise, how else can the list command show which line of code is currently being executed? We can use the open source jclasslib software to view the contents of the class file, and a standard class file contains the following information:

Basic information

Constant pool

Interface

Attribute

Parent class

Field

Method

Code attribute

Line number attribute

Local variable scale

As shown in the following figure, the most important part is the Code attribute, which has the line number attribute LineNumberTable under the Code attribute, which is the key that the debugger uses to associate bytecode with source code. For class files, you can refer to:

Http://ginobefunny.com/post/deep_in_jvm_notes_part4/

Digression: how to debug when there is no source code?

If there is no source code, although you can use step to step in jdb, there is no way to display the currently running code, which is simply blind. At this time, you can only use bytecode debugging tools. Common bytecode debuggers are: Bytecode Visualizer, JSwat Debugger, Java ByteCode Debugger (JBCD) and so on. Refer to:

Https://reverseengineering.stackexchange.com/questions/7991/java-class-bytecode-debugger

Third, about remote debugging

Through the study of jdb, we are getting closer and closer to the truth of the Java debugger, but we are still short of the last step. Let's first take a look at how Java programs are debugged in IDEA. If you are curious, you may have discovered the following secrets when debugging programs in IDEA:

Or when debugging tomcat, there is a similar string of parameters that look like a spell:

Once you understand this string of magic parameters, you will break the spell of the Java debugger before you realize what the Java debugger really looks like:

"C:\ Program Files\ Java\ jdk1.8.0_111\ bin\ java"-agentlib:jdwp=transport=dt_socket,address=127.0.0.1:20060,suspend=y,server=n FooConnected to the target VM, address: '127.0.1 jdk1.8.0_111 20060, transport:' socket'

There are two key points:

The Java program runs with the-agentlib parameter, which is used to indicate the extra dynamic library files loaded by JVM at startup. The-agentlib parameter is not the same as-javaagent, this library file should be a native program (JNI) written by C _ javaagent +, similar to the jdwp here, which corresponds to a jdwp.dll library file on Windows and a jdwp.so file on Linux. So what exactly does this jdwp library file do? What does the string of parameters behind it mean?

Socket seems to be mentioned in the parameters of jdwp, and there is an IP address and port number such as address=127.0.0.1:20060, and the following Connected to the target VM also seems to indicate that the debugger is connected to such a network address, so what exactly is this address? Since this is local debugging, the IP address is 127.0.0.1, so if it is remote debugging, is it also supported here?

On the Run/Debug Configuration configuration page of IDEA, you can also add a remote debugging. In the interface shown below, you can find that the above series of spell parameters appear again:

Before we actually start remote debugging, we might as well take these questions to learn the basics of the Java debugger. More ways to play IDEA: IntelliJ IDEA content aggregation

IV. Brief introduction of Java debugging principle and JPDA

In the martial arts world, the martial arts of the world can be divided into two kinds: one pays attention to novel moves, can be surprised when making moves, and is good at using the characteristics of weapons and their own skillful techniques to attack the enemy unprepared; the other pays attention to internal skills, even the most common moves, combined with their own deep internal force, can also have the potential of thunder when making moves. In fact, in the world of technology, martial arts can also be divided into two kinds: skills and principles.

So much of the above, whether you have mastered all the debugging skills of IDEA or memorized all the commands of jdb, it is just a change in style, so let's take a look at the inner heart method of the debugger.

4.1 JPDA

We know that Java programs run on JVM. To debug Java programs, we actually need to ask JVM for the status of the current running state, issue certain instructions to JVM, or accept callbacks from JVM. In order to debug Java programs, JVM provides a set of tools and interfaces for debugging. Together, we call it JPDA (Java Platform Debugger Architecture,Java platform debugging Architecture).

This system provides developers with a complete set of API for debugging Java programs, which is a set of interfaces and protocols for developing Java debugging tools. In essence, it is a channel and a set of tools for us to go to the virtual machine and examine the running state of the virtual machine.

JPDA consists of three relatively independent levels and defines how they interact with each other. These three levels from low to high are Java virtual machine tool interface (JVMTI), Java debug line protocol (JDWP) and Java debug interface (JDI), as shown in the following figure (picture from IBM developerWorks):

These three modules break down the debugging process into several natural concepts: the debugger and debuggee, and the communicator among them. The debugger runs on the Java virtual machine we want to debug, and it can monitor the information of the current virtual machine through the standard interface of JVMTI; the debugger defines the debugging interfaces that the user can use, through which the user can send debugging commands to the debugged virtual machine, while the debugger accepts and displays the debugging results.

Between the debugger and the debugger, debugging commands and debugging results are transmitted through the communication protocol of JDWP. All commands are encapsulated into JDWP command packages, which are sent to the debugger through the transport layer. After receiving the JDWP command package, the debugger parses the command and converts it into a call to JVMTI, which runs on the debugger. Similarly, the running result of JVMTI is formatted as a JDWP packet, sent to the debugger and returned to the JDI call. Debugger developers get the data and issue instructions through JDI.

For more information, please refer to

Https://www.ibm.com/developerworks/cn/java/j-lo-jpda1/index.html

4.2 Connectors & Transport

At this point, we already know that jdwp is a communication protocol between the debugger and the program being debugged. But the jdwp in the command-line argument-agentlib:jdwp=transport=dt_socket,address=127.0.0.1:20060,suspend=y,server=n seems to be more than that.

In fact, in this place, the jdwp.dll library file concatenates the three parts of JDI,JDWP,JVMTI into a whole, which not only invokes the debugging capabilities provided by the local JVMTI, but also implements the JDWP communication protocol to satisfy the communication between JVMTI and JDI.

To fully understand the meaning of this string of parameters, we also need to learn two concepts: Connectors (connector) and Transport (transmission).

There are five common connectors, which refer to the way JDWP establishes a connection:

Socket-attaching connector

Shared-memory attaching connector

Socket-listening connector

Shared-memory listening connector

Command-line launching connector

The difference between attaching connector and listening connector lies in whether the debugger acts as the server or the debugger acts as the server.

Transmission refers to the communication mode of JDWP. Once a connection is established between the debugger and the program being debugged, they need to communicate with each other. At present, there are two ways of communication: Socket (socket) and Shared-memory (shared memory, only used on the Windows platform).

4.3 actual combat remote debugging

From the above study, we learned that the Java debugger and the debugged program are running in the form of Cmax S architecture. First, one end must be started as a server, and then the other segment must be connected to the client. If the debugged program runs on the server side, the following command line arguments must be added:

# java-agentlib:jdwp=transport=dt_socket,server=y,address=5005 Test# java-agentlib:jdwp=transport=dt_shmem,server=y,address=javadebug Test

The first sentence is to start the program with socket communication mode, the second sentence is to start the program with shared memory, socket mode needs to specify a port number, the debugger uses this port number to connect to it, shared memory mode needs to specify a connection name, not a port number.

After the program is running, you can use the-attach parameter of jdb to connect the debugger to the program being debugged:

# jdb-attach 500 jdb-attach javadebug

On Windows platforms, the first command reports such an error: java.io.IOException: shmemBase_attach failed: The system cannot find the file specified, because jdb-attach uses the system default transport to establish the connection, while the default transport on Windows is shared memory. To connect in socket mode on Windows, use the jdb-connect command, but the parameters of the command are not easy to remember in writing:

# jdb-connect com.sun.jdi.SocketAttach:hostname=localhost,port=5005# jdb-connect com.sun.jdi.SharedMemoryAttach:name=javadebug

If, in turn, you want the debugger to run as a server, execute the following command:

# jdb-listen javadebug

The Java program then connects to the debugger with the following parameters:

# java-agentlib:jdwp=transport=dt_shmem,address=javadebug, suspend=y Test# java-agentlib:jdwp=transport=dt_socket,address=127.0.0.1:5005,suspend=y,server=n

Finally, we look back at this string of spell parameters printed by IDEA, and we can boldly guess that when debugging, IDEA first starts the debugger as a server and listens on port 20060, and then the Java program connects to that port in the way of socket communication, and pauses JVM to wait for debugging.

"C:\ Program Files\ Java\ jdk1.8.0_111\ bin\ java"-agentlib:jdwp=transport=dt_socket,address=127.0.0.1:20060,suspend=y,server=n FooConnected to the target VM, address: '127.0.0.1 jdk1.8.0_111 20060, transport:' socket' so far, I believe you have a better understanding of "what is the method of IntelliJ IDEA remote debugging". You might as well do it in practice! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.