At 04:27 PM 1/20/00 -0800, Suresh Ramaswamy wrote:
>Hi,
>
>We have a executable written in C that starts up a JVM (using JNI) and
>calls various Java methods. I'm using JDE 2.1.6beta16 with Emacs 20.3.1
>on WinNT 4.0 to connect to the remote JVM and debug the Java code. After
>some trial and error, I have been able to get this setup working. But,
>I have some questions and would appreciate some clarifications.
>
>1) I use JDebug->Processes->Start Debugger to start after loading up
> the Java file that I want to debug. Then, I use JDebug->Processes->
> Attach Process->Via Shared Memory to attach to the running VM.
> This command prompts me for the process name, and if I enter the
> process name (as shown in the WinNT Task Mgr), I get the following
> error.
>
> ------------ Contents of ifbld80.exe(4) buffer ------------
> *** Debugger Output for Process ifbld80.exe(3) ***
>
> Error: cannot attach process ifbld80.exe.
> Reason: Error occured managing application streams.
> -----------------------------------------------------------
>
> ------------ Contents of *JDebug* buffer ------------
> javaw -classpath
>d:/users/sxramasw/emacs/jde-2.1.6beta16/java/lib/jde.jar;e:/jpda/lib/jpda.jar
>jde.debugger.Main
>
> (jde-dbo-init-debug-session)
>
> JDE> -1 137 attach_shmem 4 ifbld80.exe
>
> (jde-dbo-command-error 137 "Error occured managing application streams")
> -----------------------------------------------------------
>
> It turns out that I have to enter the JVM password (which is always
> javadebug for JDK 1.2.2). Is this correct? If so, should the prompt
> be changed to "Remote JVM Password:"?
>
We have a similar scenario with one of our products. It is a very large C
application that launches a vm to run Java code. The product reads a java
options file from the bin directory in which you can specify arguments to
the internal vm. When we want to debug Java code, we set the vm arguments
as follows (for Windows and JDK 1.2):
-Xdebug
-Xrunjdwp,transport=dt_shmem,address=XXXX,server=y,suspend=n
-Xnoagent
-Djava.compiler=NONE
where XXXX is an arbitrary name that is used to rendezvous with the
debugger. In other words, when JDEbug prompts you to enter a name, you
enter XXXX.
On Unix, we use sockets, so the second option becomes
-Xrunjdwp,transport=dt_socket,address=XXXX,server=y,suspend=n
where XXXX is the name of the socket on which the application listens for
an attach message from a debugger.
Note that the third and fourth options are not necessary for JDK 1.3.
>2) Do Attach Process->On Local Host and Attach Process->On Remote Host
> work on NT? I tried Attach Process->On Local Host and it prompted me
> for a Process Port. What is this port number and how do I figure out
> what to enter here?
>
See above.
>3) When you hit a break-point, how do you display the stack?
>
Execute JDEbug->Show Buffer->Locals.
This will display the locals buffer which is updated to display all local
variables as you step through a program.
>4) Is there anyway to make the Debugger output buffer scroll down to the
> bottom automatically? I thought someone had asked about this a while
> ago and Paul had said he would add it in the next beta. Does this work
> for normal Java debugging?
>
This is a bug that I intend to fix. Patience please.
>5) Any idea when the up/down-stack and conditional breakpoint support
> will be available?
>
Within the next two weeks.
The next release will implement another way to rendevous with an
application in which the target process attaches itself to the debugger. In
your case, what will happen is the following. First, you must tell the JDE
that your application is an executable
via the configuration variable jde-run-executable. Setting this variable to
the path of your application's executable causes the JDE->Run App and
JDE->Debug App commands to run the specified executable instead of a vm.
You must also configure your internal
vm so that it starts with the following options:
-Xdebug
-Xrunjdwp,transport=dt_shmem,address=XXXX
-Xnoagent
-Djava.compiler=NONE
These options tell the vm to start, attach to a running debugger (i.e.,
JDEbug) on socket XXXX, and then halt before loading the application main
class.
Then, when you execute JDE->Debug App, the JDE will first start the
debugger and tell it to listen on a socket (that you can specify) for a
target process. The JDE will then run your executable which will then
attach itself to JDEbug and halt, waiting for you to set breakpoints and
continue execution.
The advantage of this connection method is that it allows you to debug the
startup Java code of an executable that contains an embedded Java vm.
- Paul
