[Expert] Remote debugging of Java application

Bonjour,

Je travaille sur une machine Windows mais j'ai installé une application Java sur une machine Sun. C'est une application developpée par une autre équipe
qui se trouve à Manille.

Pour comprendre comment marche cette application, j'ai rajouté des logs
avec log4j. Le problème est que certains logs apparaissent mais pas
tous ceux que je voulais obtenir.

Une première solution, la plus basique, serait de rajouter encore plus de logs dans l'application pour savoir exactement ce qui se passe et par quelles branches de code l'execution de déroule.

Puis je me suis dit, peut être aussi que le plus élégant serait de deboguer cette application Java depuis ma machine Windows. Est ce que vous avez une idée de la démarche ? Avec Eclipse ?

J'ai déja debugée des applications J2EE à partir d'eclipse mais il
fallait lancer tomcat avec les options "jpda start" et configuré
un numéro de port TCP.... Mais dans mon appli il n'y a pas tout ça....

Bon en faisant des recherches sur Internet, je suis tombé sur
ça :

http://java.sun.com/products/jpda/readme.html

Java[tm] Platform Debugger Architecture

Platform Debugger Architecture
Release Information
JavaTM Platform Debugger Architecture (JPDA) is the new debugging support for the Java 2 Platform. JPDA provides all the infrastructure needed to build professional end-user debugger applications. Check the license agreement for redistribution information.

JPDA has been tested most on the Classic Virtual Machine platforms shipped with the Java 2 Software Development Kit (J2SDK), version 1.2.2, and it is known to work well on those platforms. However, JPDA can be used, with restrictions, on any of the following versions of SunTM VMs. Click on the VM you use to learn more about the bugs and limitations associated with it.


Sun Win32 Classic VM versions 1.2, 1.2.1, 1.2.2 and higher.
Sun Win32 HotSpotTM Performance Engine version 1.0 and higher.
Sun SolarisTM Reference (Classic) VM versions 1.2, 1.2.1, 1.2.2 and higher.
Sun SolarisTM Production VM versions 1.2.1_03 and higher.
Sun SolarisTM HotSpotTM Performance Engine version 1.0 and higher.

We are very interested in your input. You may send comments to the JPDA team by going to: The J2SE feedback site and selecting Java Platform Debugger Architecture from the Subject pulldown menu.

The Debugging Interfaces
This release contains the reference implementations of the Java Debug Interface (JDI) and the Java Debug Wire Protocol (JDWP). See the documentation for more information on these interfaces. We provide a set of class files and native libraries which implement the JDI. This implementation uses the JDWP to communicate between a debugger virtual machine (front-end) and target virtual machine (back-end). The front-end support is contained in a set of class files. The back-end support is contained in native libraries that are loaded into the target virtual machine when an application is debugged.

The Java Virtual Machine Debugging Interface (JVMDI) is a low level native interface that is provided by a Java virtual machine.

Contents
The doc directory contains overview documentation for the various interfaces as well as detailed documentation for the JDI.

The lib directory contains jpda.jar: the JDI specification packages, the reference implementation of the JDI, and example debugger applications.

The examples directory contains examples.jar, source code for the example applications jdb and javadt.

On Win32 platforms, the bin directory contains

jdb.exe, a line mode debugger implemented with JDI.
javadt.exe, a simple, graphical debugger implemented with JDI.
jdwp.dll, the native library that implements back-end support for the JDI.
dt_socket.dll and dt_shmem.dll, the native libraries that implement socket and shared memory transports used by JDI and JDWP.

On Solaris platforms, the bin directory contains

jdb, a line mode debugger implemented with JDI.
javadt, a simple, graphical debugger implemented with JDI.

On Solaris platforms, the lib/sparc directory contains

libjdwp.so, the native library that implements back-end support for the JDI.
libdt_socket.so, the native library that implements the socket transports used by JDWP.

Manually Launching the Application VM
If you are running the version of jdb provided in this release, the application VM is launched for you with the debugger back end loaded. However, in the following cases, you will be launching your own application VM, either by hand or in your implementation.

Remote debugging with the -attach or -listen jdb option.
You are implementing a debugger which uses the JDWP directly.
You are implementing a debugger back end which uses JVMDI.

Currently, the first two cases require a command line like the following:

java -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y -classpath class-path class-name

The -Xdebug option enables debugging. The -Xnoagent disables the default sun.tools.debug debug Agent. The -Djava.compiler=NONE disables the JIT compiler.

For the third case, you must use the same command line options as described above, but you are free to use your own mechanism for loading the JVMDI client into the application VM. You do not need to use -Xrun.

The Connection and Invocation Details document contains more information on necessary VM invocation options and sub-options of -Xrunjdwp.

Known Bugs and Limitations
All Platforms
The following bugs and limitation exist on all platforms.

On all known platforms, incorrectly generated local variable tables can cause the back-end to crash (bug #4244598). IBM Jikes compiler has been known to generate invalid tables in the presence of unused local variables. The 1.2 javac compiler generates invalid tables under obscure circumstances (bug #4243183).
4230262: Out of memory conditions in the target VM are not handled gracefully in all situations. In particular, an out of memory condition during the processing of method entry or exception events can lead to stack overflow in the target VM.
4252005: EventQueue.remove can throw an ObjectCollectedException if an event is requested with suspend policy SUSPEND_NONE and associated objects or classes are garbage-collected before the event is processed.
4252790: Locatable.location() should return null for abstract or native methods. Instead it returns an invalid location which will result in internal exceptions when used elsewhere. Use Method.isNative and Method.isAbstract to work around this bug.

Sun Win32 Production VM and Solaris Reference VM, 1.2.2
The following bugs exist in the 1.2.2 Win32 classic VM and Solaris Reference VM JVMDI implementations.
Attempts to retrieve a method's bytecodes can result in a hang.
4184934: Returned method bytecodes can contain "quick" instruction optimizations instead of the original method bytecodes.
4184913: Step events cannot be requested for the entire VM at once; instead, they must be requested on a per-thread basis.

Sun Win32 Production VM and Solaris Reference VM, 1.2 and 1.2.1
In addition to the bugs listed above for version 1.2.2, the following bugs exist in the 1.2 and 1.2.1 Win32 classic VM and Solaris Reference VM JVMDI implementations.

4195595: Some events that occur at the same location are not properly combined into event sets; instead, they are reported separately as single-element event sets. This happens when events of different kinds occur at the same thread and location.
4199393: For classes compiled without -g, JDI responds to queries for local variables with empty lists instead of throwing the appropriate AbsentInformationException.
4195595: Some breakpoints at the start of methods are not reported if you are also stepping over the method invocation.
4191820: Incorrect local variable values are reported during method exit events.
4184924: Redundant step events are generated when instruction stepping through quicked instructions for the first time.
Some crashes have been reported during step operations.

Sun Win32 Production VM and Solaris Reference VM, earlier than 1.2
Releases of the Sun Classic VM earlier than 1.2 cannot be used with this release of JPDA.

Solaris Production VM, 1.2.1_03
Important: Due to a bug in this version of the Production VM, you should set the environment variable _JAVA_JDWP_OPTIONS to "stdalloc=y" before running with this version of the Solaris Production VM with JPDA. See list below for details.

JPDA has undergone limited testing with the 1.2.1_03 Solaris Production VM. It is presumed that all Solaris Reference VM, 1.2.1 bugs also exist in this VM. The following bugs are known to exist in this version of the Solaris Production VM JVMDI implementation.

4241264: A bug in memory allocator usage causes a segmentation fault, usually fairly early in a debugging session. This can be worked around by forcing the use of the standard allocator (malloc); however, as a result there is a small chance of hanging due to contention for the malloc lock. To force the use of the standard allocator either set the _JAVA_JDWP_OPTIONS environment variable as shown above, or add "stdalloc=y" to the "-Xrunjdwp:" arguments on the launching of the back-end.
Hangs may occur caused by object creation contention for raw monitors.

Solaris Production VM, earlier than 1.2.1_03
Production releases of the Sun Solaris VM earlier than 1.2.1_03 cannot be used with this release of JPDA.

HotSpot Performance Engine 1.0 (Win32 and Solaris)
JPDA support is considered to be beta quality in version 1.0 of the Hotspot Performance Engine. The following bugs exist in this version of the HotSpot Performance Engine JVMDI implementation.

4248826: Method entry/exit events are not reported for empty methods.
4241116,4245697: Stepping is inconsistent.
4252694: Breakpoints on java.lang.Thread.resume are ignored.
4259923: Incorrect values reported for locals of type long, float, and double.
4261718: Access to ThreadGroup functionality causes VM crashes.
4259927: For classes compiled without -g, JDI responds to queries for local variables with empty lists instead of throwing the appropriate AbsentInformationException.

http://java.sun.com/products/jpda/doc/conninv.html

Java Platform Debugger Architecture - JPDA Connection and Invocation


Contents
Transports
Connectors
Sun VM Invocation Options
Debugging Plug-in Applets
Connecting with JDB



Transports
A JPDA transport is a form of inter-process communication used by a debugger application process and the virtual machine that is being debugged (often called the target VM). JDI and JDWP admit the existence of transports and refer to individual transports by a unique name, but the JDI and JDWP specifications do not require specific transport implementations to exist. Transport implementations can allow communications between processes running in a single machine, on different machines, or either.
In establishing a connection between a debugger application and a target VM, one side acts as a server, listening for a connection. At some later time the other side attaches to the listener and a connection is established. JPDA transports allow either the debugger application or the target VM to act as a server. During the establishment of a connection, transport addresses are used to identify the other side of a connection. Transport addresses are strings; their format depends on the transport implementation.

The JPDA reference implementation on Win32 provides two transports: a shared memory transport and a socket transport. The JPDA reference implementation on Solaris platforms provides a socket transport. Future versions of the JPDA reference implementation may include additional transports, Future versions of the JPDA specification may provide an interface for plugging additional transports into an implementation.

Socket Transport
The JPDA reference implementation provides a socket transport on both Solaris and Win32 platforms. The socket transport uses standard TCP/IP sockets to communicate information between debugger applications and target VM. With the socket transport, the debugger application and target VM can reside either on the same machine or on different machines. The socket transport is identified through a unique string, dt_socket. This name can be used to select the socket transport when invoking the target VM and when selecting a JDI connector.
In contexts where a client is attaching to a server, socket transport addresses have the format "<name>:<port>" where <name> is the host name and <port> is the socket port number at which it attaches or listens. In contexts where a server is waiting for a client to attach, the address consists of the port number alone (the host name is implicit).

Shared Memory Transport
In addition to the socket transport, the JPDA reference implementation provides a shared memory transport on the Win32 platform. The shared transport uses Win32 shared memory primitives to communicate information between debugger applications and target VM. With the shared memory transport, the debugger application and target VM must reside on the same machine. The shared memory transport is identified through a unique string, dt_shmem. This name can be used to select the socket transport when invoking the target VM and when selecting a JDI connector.
Shared memory transport addresses are simply names that can be used as Win32 file-mapping object names.The name string can consist of any combination of characters, excluding the backslash.

Connectors
A connector is a JDI abstraction that is used in establishing a connection between a debugger application (written to the JDI) and a target VM. Different JDI implementations are free to provide different connector implementations to match the transports and VMs they support. The connector interfaces are very general, to allow JDI to be used with varying connector implementations. Connectors are configured through a set of name/value pairs. Specific connectors accept different name/value pairs.
A good JDI client application will allow users to choose and configure any connector that may be present, but it can be beneficial to incorporate knowledge of specific connectors into the debugger to make their configuration a more pleasant user experience. The example JDB implementation provided with the JPDA illustrates this approach.

The JDI reference implementations provides several connectors which map to the available transport types and the modes of connection (launching, listening, and attaching). These connectors are described in the following sections.

Sun Command Line Launching Connector
This connector can be used by a debugger application to launch a Sun VM or any other VM which supports the same invocation options with respect to debugging. The details of launching the VM and specifying the necessary debug options are handled by the connector. The underlying transport used by this connector depends on the platform. On Win32, the shared memory transport is used. On Solaris, the socket transport is used.
This connector is uniquely identified by the name "com.sun.jdi.CommandLineLaunch".


Raw Command Line Launching Connector
This connector can be used by a debugger application to launch any VM. The entire command line must be specified and it is not edited in any way. The details of launching the VM with the given command line are handled by the connector. The underlying transport used by this connector depends on the platform. On Win32, the shared memory transport is used. On Solaris, the socket transport is used.
This connector is uniquely identified by the name "com.sun.jdi.RawCommandLineLaunch".

Socket Attaching Connector
This connector can be used by a debugger application to attach to a currently running target VM through the socket transport.. The target VM must have been invoked with options consistent with this connector's arguments described in the table below. For Sun VMs, the necessary options are described below.
This connector is uniquely identified by the name "com.sun.jdi.SocketAttach".


Shared Memory Attaching Connector
This connector can be used by a debugger application to attach to a currently running target VM through the shared memory transport..It is available only on the Win32 platform. The target VM must have been invoked with options consistent with this connectors arguments described in the table below. For Sun VMs, the necessary options are described below.
This connector is uniquely identified by the name "com.sun.jdi.SharedMemoryAttach".



Socket Listening Connector
This connector can be used by a debugger application to accept a connection from a separately invoked target VM through the socket transport.. The target VM must be invoked with options consistent with this connector's arguments described in the table below. For Sun VMs, the necessary options are described below.
This connector can accept connections from multiple target VMs.

This connector is uniquely identified by the name "com.sun.jdi.SocketListen".


Shared Memory Listening Connector
This connector can be used by a debugger application to accept a connection from a separately invoked target VM through the shared memory transport..It is available only on the Win32 platform. The target VM must be invoked with options consistent with this connectors arguments described in the table below. For Sun VMs, the necessary options are described below.
This connector can accept connections from multiple target VMs.

This connector is uniquely identified by the name "com.sun.jdi.SharedMemoryListen".


Sun VM Invocation Options
This section describes the options necessary to invoke Sun VMs for debugging. If your debugger application uses the JDI Sun Command Line Launching Connector, the appropriate options are set for you. In other cases, when the VM is invoked manually, you will need to set them.
Required Classic VM Options
The following VM invocation options are required to debug applications running under the classic VM.
-Xdebug
Enables debugging
-Xnoagent
Disables the old sun.tools.debug agent. JPDA attaches its "agent" in a different manner, described below.
-Djava.compiler=NONE
Disables the JIT compiler. Debugging with the classic VM requires that it's JIT compiler be disabled.
-Xrunjdwp:<sub-options>
Loads the JPDA reference implementation of JDWP. This library resides in the target VM and uses JVMDI and JNI to interact with it. It uses a transport and the JDWP protocol to communicate with a separate debugger application. Specific sub-options are described below.

If the Hotspot Performance Engine is installed, the -classic is necessary to select the classic VM.

Required Hotspot Performance Engine Options
The Hotspot Performance Engine requires the -Xdebug and -Xrunjdwp options described above. The -Xnoagent and -Djava.compiler=NONE options are not required; however, for compatibility, these options are accepted and ignored.
-Xrunjdwp sub-options
The -Xrunjdwp option can be further qualified with sub-options. The sub-options are specified as follows:
-Xrunjdwp:<name1>[=<value1>],<name2>[=<value2>]...

-Xrunjdwp Examples
-Xrunjdwp:transport=dt_socket,server=y,address=8000
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.
-Xrunjdwp:transport=dt_shmem,server=y,suspend=n
Choose an available shared memory transport address and print it to stdout. Listen for a shared memory connection at that address. Allow the VM to begin executing before the debugger application attaches.
-Xrunjdwp:transport=dt_socket,address=myhost:8000
Attach to a running debugger application via socket on host myhost at port 8000. Suspend this VM before main class loads.
-Xrunjdwp:transport=dt_shmem,address=mysharedmemory
Attach to a running debugger application via shared memory at transport address "mysharedmemory". Suspend this VM before main class loads.
-Xrunjdwp:transport=dt_socket,server=y,address=8000,onthrow=java.io. IOException,launch=/usr/local/bin/debugstub
Wait for an instance of java.io.IOException to be thrown in this VM. Suspend the VM (suspend=y by default). Listen for a socket connection on port 8000. Execute the following: "/usr/local/bin/debugstub dt_socket myhost:8000". This program can launch a debugger process in a separate window which will attach to this VM and begin debugging it.
-Xrunjdwp:transport=dt_shmem,server=y,onuncaught=y,launch=d:\bin\ debugstub.exe
Wait for an uncaught exception to be thrown in this VM. Suspend the VM. Select a shared memory transport address and listen for a connection at that address. Execute the following: "d:\bin\debugstub.exe dt_shmem <address>", where <address> is the selected shared memory address. This program can launch a debugger process in a separate window which will attach to this VM and begin debugging it.
Debugging Plug-in Applets
Beginning with version 1.2.2 of the Java Plug-in, applets running under the Plug-in can be debugged. The required VM options described above can be specified in the Plug-In control panel, under the "Basic" tab, in the "Java Run-Time Parameters". The debug options under the "Advanced" tab should not be used as they will enable the old sun.tools.debug debug support. In future versions of the Plug-in, these debug options will be changed to use JPDA.
JDI launching connectors cannot be used to debug Plug-in applets.

Connecting with JDB
The example implementation of JDB provided with the JPDA, provides an illustration of the usage of JDI connectors. There are "shortcut" options to JDB which assume the use of connectors known to it (that is, connectors present in the reference implementation). It also provides a way to establish a general connection using any connector. While JDB is hardly an example of a good debugger interface, it does provide a simple example of connectors in use.
In JDB, the -attach option provides access to one of the attaching connectors in the reference implementation (shared memory on Win32, sockets on Solaris). The -listen option provides access to one of the listening connectors in the reference implementation (shared memory on Win32, sockets on Solaris). A class name and arguments specified directly on the command line provide access to the Sun command line launching connector.

For example:

jdb -attach myhost:8000

is an easy way to attach to a target VM with the Socket Attaching Connector (on Solaris), and

jdb Hello 1 2 3

is an easy way to launch a target VM with the Sun Command Line Launching Connector.

However, the -connect option is also provided by JDB to handle any connector by taking an connector name and a set of arbitrary name/value argument pairs. For example the command lines above have the following equivalents.

jdb -connect com.sun.jdi.SocketAttach:host=myhost,port=8000
jdb -connect "com.sun.jdi.CommandLineLaunch:main=Hello 1 2 3"

These command lines are more cumbersome than the ones above, but the -connect option can be used with any connector. This kind of operation is a primitive example of how a JDI debugger can deal with any kind of connector while providing a simplified interface for dealing with common, well-known connectors.

Bon ben j'y suis arrivé tout seul comme un grand et grace à google...

J'ai pu débuggé mon code sous Eclipse via une machine Java distante
grace à la technologie JPDA de Java2.