At 02:23 AM 2/3/00 -0000, Larry Riedel wrote:
>
>I want to debug a running remote Java application by
>connecting to it via JPDA and using JDE 2.1.6b17.  I
>have made some effort to see how to do it, but it is
>not clear to me what to do.  I do *not* want to tell
>the JDE any particular class or source file to look
>at in advance, because I have no idea what the state
>of the running application is before I connect to it,
>although I do know the appropriate source/class paths,
>of course.
>

JDEbug can only attach itself to Java processes that are "attachable." An
attachable process is one that was started with the following virtual
machine arguments:

-Xdebug
-Xrunjdwp:transport=TRANSPORT,address=ADDRESS,server=y,suspend=n 

where TRANSPORT is either dt_shmem (shared memory connection, available
only on Windows) or dt_socket (socket connection) and ADDRESS is an
arbitrary string if TRANSPORT is dt_shmem and a port number if TRANSPORT is
dt_socket. When the JDE attach command prompts you for an address or port
number, enter ADDRESS.

In addition, the JDK 1.2.x vm requires the following arguments:

-Xnoagent
-Djava.compiler=NONE 

Here is a sample command-line for starting an "attachable" Java process
with a JDK 1.2 vm:

javaw -classpath c:/myapp/lib/myapp.jar -Xdebug -Xnoagent
  -Xrunjdwp:transport=dt_shmem,address=myapp,server=y,suspend=n 
  -Djava.compiler=NONE  com.myorg.myapp.Main

A vm can only accept a debugger connection when it is idle, for example,
waiting for input from a user.

My plan is to enhance the JDEbug attach command to tell you where the
attached process is  operating when the attach occures. You can do this
currently with JDEbug but it requires that you issues raw jdebug commands
in the *JDEbug* buffer. To do this, first suspend the attached process by
exeuting JDEbug->Processes->Suspend. Then display the attached process's
threads by executing JDEbug->Display->Threads. Finally, for each thread of
interest, enter

app_id cmd_id get_thread thread_id

in the *JDEBug* command buffer where app_id is the numeric id of the
attached process, cmd_id is one greater than the id of the previous cmd
sent to the debugger for the attached process, and thread_id is the numeric
id of the thread (displayed in the output of the Display->Threads command).
The command will return the call stack for the thread.

- Paul 
  

Reply via email to