Remote Debugging Java Applications

After my previous article about Remote Debugging .NET Applications using Visual Studio 2010, I was curious to see how Remote Debugging works for Java Applications. This blog post covers Remote Debugging Java Applications using NetBeans 7.0.

The basic concepts of Remote Debugging are the same for .NET and Java but the process of setting up the host and remote computers varies between Visual Studio and NetBeans. Similar to the .NET application used in the previous post, the screen shots correspond to a simple Java application which would popup a MessageDialog on a button click. Get the code here.

Before configuring the host and remote computers, it is vital to understand the Java Platform Debugger Architecture (JPDA). JPDA provides the infrastructure you need to build end-user debugger applications for the Java Platform. It includes the following APIs broken into three layers -

• Java Debug Interface (JDI), a high-level Java programming language interface including support for remote debugging
• Java Debug Wire Protocol (JDWP), which defines the format of information and requests transferred between the process being debugged and the debugger front end
• JVM Tools Interface (JVM TI), which is a low-level native interface that defines the services a JVM provides for tools such debuggers and profilers

Configuring the Remote Computer

Run the Java application using the -Xdebug and -Xrunjdwp options from the command line.

java -Xdebug -Xrunjdwp:transport=dt_socket,address=6000,server=y -jar RemoteDebugging.jar

Here's a description of the options of the java command -

Option	Description
-Xdebug	Enables debugging support in the VM
-Xrunjdwp	Loads in-process debugging libraries and specifies the kind of connection to be made

The -Xrunjdwp option has several sub options. Here are the descriptions of the ones that are used above -

Option	Description
transport	Name of the transport to user in connecting to debugger application
address	Transport address for the connection If server=n, attempt to attach to debugger application at this address If server=y, listen for a connection at this address
server	If y, listen for a debugger application to attach If n, attach to the debugger application at the specified address

By default the application starts in suspended mode. In suspended mode the application waits for a debugger to attach itself to the server at the specified port before the application starts.

Configuring the Host Computer

The host computer is the system running NetBeans 7.0. Open the code of the application in NetBeans and select "Attach Debugger". Specify the Connector as SocketAttach, the Host as the hostname of the remote system and the Transport and Port as specified above.

Specify the breakpoints in the code and they would hit appropriately. There are two major bottlenecks in Remote Debugging -

• The code from which the executable was built should be available at the time of debugging
• Applications cannot be configured for Remote Debugging at runtime. The -Xdebug option must be specified at the instantiation of the application, making debugging live production code difficult

Before I conclude, here's an article from OTN (Oracle Technology Network) on the Java Platform Debugger Architecture. Visit it if you would like a deeper insight into Java Debugging. The schematic of the JPDA is from a weblog, check it out here.

Remote Debugging .NET Applications

From the past few days I have been stuck in resolving a bug which cropped up in one of my applications after it went to Production. The worst part was that it was a machine-specific issue and we couldn't reproduce it in any of our development systems. While trying to find a solution for this, I came across the concept of Remote Debugging.

Remote debugging is debugging a remotely running application through a development environment running on a system other than the one running the app. This is done by connecting the remote system to the system containing the development environment (in turn the debugger) through Sockets. Theoretically this is achieved in two steps -

• The remote computer would open a socket and listen to debug instructions through it. These instructions are feed to the application that is being debugged and the application responds appropriately
• The debugger would connect to the socket opened by the remote system and send instructions through it

Remote debugging can be used in many live situations. Examples include -

• Debugging a machine specific issue which can't be reproduced on systems running the development environment (my exact requirement :))
• Debugging applications which can run only on the server machine due to dependent third party libraries that cannot be used in the development machine

In this blog post, I will be focusing on Remote Debugging .NET applications through Visual Studio 2010. The screen shots correspond to a simple .NET application which would popup a MessageBox on a button click. Get the code here.

Configuring the Host Computer

The host computer is the computer containing the development environment. This is the system running Visual Studio 2010. To enable Remote Debugging, make sure the following ports are open on the host computer -

Ports	Protocol	Description
135	TCP	Required
500, 4500	UDP	Required if your domain policy requires network communication to be performed through IPSec

IPSec (Internet Protocol Security) is a protocol suite for securing IP communications authenticating and encrypting each IP packet of a communication session. Read more about IPSec here. However I am not going cover IPSec in this post.

You can check if the ports are open by using the telnet command at command prompt (telnet isn't installed by default on Windows 7. Install it from the "Turn Windows features on or off" section in the Control Panel).

Configuring the Remote Computer

To configure the remote system for debugging, either download and install the Microsoft Visual Studio 2010 Remote Debugger or copy the folder Remote Debugger from the Visual Studio install path, which is typically C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE. The Remote Debugger is available for three configurations - x86, x64 and ia64.

Visual Studio takes the .pdb files for debugging from the remote system for managed code. So copy the .pdb from the bin/Debug folder of the project to the remote system. Put this folder on share so that Visual Studio can access it later.

To enable Remote Debugging, make sure the following ports are open on the host computer -

Ports	Protocol	Description
135, 139, 445	TCP	Required
137, 138	UDP	Required
500, 4500	UDP	Required if your domain policy requires network communication to be performed through IPSec
80	TCP	Required for Web Server debugging

That's it; both the host and remote computers are up and ready for Remote Debugging.

Start the application on the remote system if it isn't running already. Also start the Visual Studio Remote Debugging Monitor on the remote system using the msvsmon.exe from the appropriate configuration folder in the Remote Debugger directory (The screenshot uses the x86 version).

Open the code in Visual Studio on the host system and select "Attach to Process". Typically Visual Studio identifies the .pdb file of the remote system if it can. If it doesn't, open the Modules screen from Debug -> Windows -> Modules. Check the Symbol Status of the .exe file which is being debugged and if it shows "Cannot find or open the PDB file" right-click on it and select "Load Symbols From" and specific the share path through the "Symbol Path".

Specify the breakpoints in the code and they would hit appropriately. There are two major bottlenecks in Remote Debugging -

• The code from which the executable was built should be available at the time of debugging
• The above mentioned ports should be open for debugging. Most of the developers wouldn't have administrative privileges on the client systems, so they would require people with sufficient privileges to open up these ports. However several organizations wouldn't prefer opening up ports for incoming connections

Before I conclude, here's an article from MSDN on how to Set Up Remote Debugging. Visit it if you would like a deeper insight into Remote Debugging.