Debug is the work that the programmer can't avoid. There are many kinds of debugging methods, but in the final analysis, it is to find the code that triggered the wrong. For example, in a Linux application, the segmentation fault is considered to be one of the most common errors. This error will occur when the program attempts to access the memory that is not assigned and terminates due to segmentation violations. To correct this error, you need to find the line of code that triggered the behavior. Once a problem with a problem, this is also helpful for knowing the context that triggers an error and its associated values, variables, and methods. Using the debugger will make the findings are quite simple.
The Eclipse debugger and the Debug view Eclipse platform features the built-in Java debugger, which provides all standard debugging features, including single-step execution, setting breakpoints, and values, and resume threads. . In addition, you can debug applications running on remote machines. The Eclipse platform is mainly a Java development environment, but its architecture is also open to other programming languages. As you will see below, the DEBUG view of the same Eclipse can also be used in C and C programming languages.
Eclipse Platform Workbench and its tools are built based on the Java Development Tool (JDT) component. These components provide the following features to Eclipse:
Project Management Tool Perspective and View Builder, Editor, Search, and Build Debugger
The Eclipse debugger itself exists as a standard plug-in included in the Eclipse binaries. Eclipse also has a special debug view that allows you to manage debugging and running in the workbench. It displays the stack frames of their suspended threads for each target in debug. The various threads in the program appear as the node of the tree, and the DEBUG view shows the process of each target in the run. If a thread is held, its stack frame is displayed as a child element.
Before you start using the Eclipse debugger, assume that you have installed the appropriate Java SDK / JRE (I recommend you use Java VM 1.4) and Eclipse platform SDK 2.0 / 2.1, and both work normally. In general, first test the debug options with Eclipse samples is a good idea. If you want to develop and debug C / C projects, you also need to get and install the C / C Development Tool (C / C Development Tool, CDT). For links to Java SDK / JRE, Eclipse platforms, samples, and CDT, see the references later in this article. Figure 1 shows a conventional view of the Debug user interface.
Figure 1. General view of the Eclipse Debug view user interface
Debug Java requires complete compilation and running code before you can debug your project. You first need to create a run configuration for your application and confirm it normally. After that, you need to use the Run> Debug ... menu to set the debug configuration in the same way. You also need to choose a class that is used by the debugger as the main Java class (also see Figure 2). For a project, you want to have several debugging configurations. When the debugger is started (via run> debug ...), it will open it in a new window, you can prepare to start debugging.
Figure 2. Set the primary Java class for the project in the debug configuration
The following is an example indication information for the most common Eclipse debugging operation:
Set breakpoint When you start the application for debugging, the Eclipse automatically switches to the Debug perspective. No doubtful, the most common debugging process is to set breakpoints to allow the variables and values in the conditional statements and cycles. To set a breakpoint in the Package Explorer view of the Java perspective, double-click the selected source code file to open it in the editor. Traverse all code, place the cursor on the tagbar of the row containing suspicious code (on the left side of the editor area). Double click to set breakpoints (see Figure 3). Figure 3. Two breakpoint markers can be seen at the edge of the editor
Now start the debug session through the Run> Debug ... menu. One thing is important, don't put the number statements in the same row, because you cannot skip or set the intermittent point on multiple statements in the same line (see Figure 4).
Figure 4. View of the arrows on the left side pointing out the row currently executing
Conditional breakpoints Once you find an error, you will want to know what you are doing before the crash. One way to complete this work is a single-step executive program, one sentence until the problem is reached. Sometimes a better way is to run a certain code and terminate it in a problem, so that you can check the data in this location. To achieve this, you may have to declare the condition breakpoint that is triggered whenever the value of the expression is changed (see Figure 5). In addition, you can also use code assist in the input conditional expression.
Figure 5. Setting the condition breakpoint trigger
The value of the expression to be evaluated in the editor of the DEBUG perspective is selected, and the setup set has a breakpoint and select the Inspect option in the context menu (see Figure 6). The expression is evaluated in the context of the current stack frame, and its result is displayed in the Expressions view of the Display window.
Figure 6. Value of expressions with an Inspect option
View Variable Variables View (in the Display window) Displays the variable values in the selected stack frame (see Figure 7). To view the requested variable, just expand the tree in the Variables view until you see the requested element. You can also view variables in the Variables view while you can perform code in a DEBUG view.
Figure 7. View variables in the DISPLAY window
When the debugger stops on the breakpoint, you can continue the debugger session by selecting the Step over option on the Run> Debug ... menu (see Figure 8). This will skip the highlighted code line and perform the next line in the same method (or it continues in the method of calling the current method). As the result of the last step, the change in the change is highlighted (the default is red), and the color used can be specified in the "Changed Variable Value Color" preferences (specified by Debug Variable Views).
Figure 8. Debugger command in the Run ... menu
To hold the execution of the thread in the Debug view, select a running thread and click the Suspend button in the Debug View toolbar. The current call stack of the thread is displayed, and the currently executed row is highlighted in the editor of the DEBUG perspective.
When you hold the thread, place the cursor to the variable in the Java editor, the value of the variable is displayed in a small floating window. Similarly, the top stack frame of the thread is automatically selected, and the visual variable in the stack frame is displayed in the Variables view. You can check the corresponding variables by clicking the variable name in the Variables view.
Heat Exchange Error Correction: Real Time Code Refractive If you run JVM 1.4 (Java Virtual Machine, Java Virtual Machine), Eclipse 2.0.2 and 2.1 provide new features called HotSwap Bug Fixing (unable to use JVM 1.3 or lower version - Refer to Figure 9). It allows for a series of steps that are changed in the debugger session process, which is much more step more than "exiting the application, changing source code, recompiling, and then starting another debugging session". To use this feature, simply change the code in the editor and restore debugging. This feature can be used because JVM 1.4 is compatible with Java Platform Debugger Architecture, JPDA. JPDA implements the ability to replace the modified code in the running application. Of course, this function is extremely useful when launching your application or finding an error point. Figure 9. The heat exchange error correction function cannot be used in JVM 1.3 and lower versions
If you have not performed completely, select the Terminate option in the context menu in the Debug view. A common error is that you use Debug or Run in the debugger session instead of resume. This will start another debugger session instead of continuing the current session.
The remote debugging Eclipse debugger provides an interesting option that can be used to debug remote applications. It can be connected to a remote VM running a Java application and connect it to an internal debugger. Handling the remote debug session is very similar to local debugging. However, the remote debug configuration requires different settings for the Run> Debug ... window. You first want to select the Remote Java Application item in the left side view, click the New button. This creates a new remote boot configuration and displays three tabs: Connect, Source, and Common.
In the Project Domain of the Connect tab, select the item used as the start preference (for finding the source code). In the Host domain of the Connect tab, enter the IP address or domain name of the remote host running the Java program. In the port domain of the Connect tab, enter the port remote VM to accept the connection. In general, the port is specified at the start of the remote VM. When you want the debugger to determine if the TERMINATE command is available in the remote session, you can select the Allow Termination of Remote VM option. If you want to terminate the connected VM, select this option. Now when you select the debug option, the debugger will attempt to connect the remote VM in the specified address and port and display the result in the Debug view.
If the starter cannot be connected to the VM on the specified location, an error message will be displayed. In general, the availability of remote debugging features completely depends entirely on Java VM (virtual machines, virtual machines) running on the remote host. Figure 10 shows the setting of the connection properties of the remote debug session.
Figure 10. Set the connection properties of the remote debug session
Debugging other languages Java is the primary language of the Eclipse platform. However, the Eclipse platform is also an expandable platform that supports many other languages, and the most important thing is to support C / C (because of its popularity). Eclipse supports C / C with a C / C development tool (CDT). See Resources for related links. CDT extends the standard Eclipse Debug view by debugging C / C code, while the CDT Debug view allows you to manage debugging of C / C projects in the workbench. The CDT does not include its internal debugger, but it provides a front end to the GNU GDB debugger that must be used locally. After downloading and installing the CDT, just switch to the Debug view, you can start debugging the current C / C project (see Resources to get a link to how to install CDT). This allows you to set (and change) the breakpoint in the code and track the variables and registers during the execution process. The Eclipse debugger displays the stack frame of the suspended thread of each target in your debug. The various threads in the program appear as the node of the tree. It shows the process of running the targets. Remember that when GNU GDB debugs a program with debug symbolic link, it is most effective. This is implemented by command line parameters -g during the compilation process. For more information, please use the -ggdb switch, which contains debug symbols specific to GNU GDB.
If you want to debug servlet, use Sysdeo Eclipse Tomcat Launcher. The plugin allows you to manage Tomcat 4.x / 3.3 servlet containers (by creating and importing a Tomcat WAR project). It also registers a Tomcat process in an internal Java Eclipse debugger so you can easily debug Tomcat applications. There are several other Eclipse plugins that enable us to use the internal Eclipse debugger, such as the Eclipse plugin, RESIN plug-in and X-Parrots ServleTexec plugins for CACTUS. The links of these plugins can be obtained in the following references.
Conclusion The Eclipse platform provides a built-in Java debugger with standard debugging capabilities, including single-step execution, setting breakpoints, and values, check variables, and resumption of the ability to resume threads. It can also be used to debug applications running on remote machines. The Eclipse platform is mainly a Java development environment, but the DEBUG view of the same Eclipse can also be used for C and C programming languages.
Reference
Add the Eclipse.org to the Eclipse platform community and download the platform. The Eclipse platform source code is permitted by a common public license (Common public license). You can also find the terms of the Eclipse project in Eclipse.org, and description, as well as technical articles and newsgroups. The Eclipse platform white paper describes the main components and functions of Eclipse. Download C / C development tools in Eclipse.org. Download Sysdeo Eclipse Tomcat Launcher. Here are some links to the Eclipse plugin for servlet:
CACTUS's Eclipse plugin Resin plug-in X-Parrots servletexec plugin views the classification registry of the Eclipse plugin. The following article can help you start learning to debug with Eclipse:
