At 08:57 AM 9/1/00 +0200, Mattias Waldau wrote:
>I have tried the tricks posted, like using 127.0.0.1, and making sure that I
>only have one VM. (If you install SDK1.3 on Windows, you automatically get 2
>VM, one on top c:\jdk1.3 and one JRE within program files.) The debugger
>fails so early, so there are no window changes done, and therefor the
>contents in the lower of the 2 buffers that Paul Kinnucan want to see
>doesn't exist.
>
>
>Instead of using sockets, I started up the process to be debugged in a
>separate process and attached to it using shared memory. Everything worked
>fine - at least I could see the trace of methods entering. Jippi! So it
>seems that Paul Kinnucan has pinpointed the error right.
>
>Now I am looking for the flag that tells JDE to used shared memory instead
>of sockets.
There isn't a flag. There are two kinds of connections involved with
JDEbug: (1) The connection between the vm that runs JDEbug and the vm that
runs the debuggee applicaitons and (2) the connection between the vm that
runs JDEbug and Emacs. There are actually two connections between Emacs and
the vm that runs JDEbug: a standard I/O connection and a socket connection.
The standard I/O connection is used for sending debug commands to JDEbug.
The socket connection is used to send input (via JDEbug) to the standard
input of the debuggee and to send standard output and standard error from
the debuggee (via JDEBug) to Emacs.
| <-------SIO--------> |
Emacs/JDE | | JDEbug/vm <--shared
mem--> debuggee/vm
| <----socket-------> |
It appears that the problem is with the socket connection used to interface
the JDE/Emacs to the standard I/O of the debuggee process. It works fine on
my Windows 95 and Windows/NT systems. I cannot for the life of me figure
out why other people are having a problem. In some cases, using the
absolute host address of the Windows machine seems to clear up the problem.
Note that the connection between JDEbug vm and the debuggee vm is the same
whether JDEbug launches the debuggee vm or you launch it separately and
then attach JDEbug to the debuggee. Note also that it is not possible to
create a standard I/O interface between JDEbug and a debuggee process that
you have launched yourself. This explains why you are able to debug in
attach mode, i.e., JDEbug never attempts to create a socket for the SIO
interface so the socket problem never arises.
I plan to keep working on the socket problem. It may be possible to write a
diagnostic program that shows whether the problem exists, i.e., a
standalone Emacs lisp program that tried to connect to a socket created by
a Java process. The problem could also be a threading problem since the SIO
interface process runs on its own thread. If anyone is inclined to look at
the relevant JDEbug code and see if they can spot any problem, I'd be most
grateful. The relevent code is the initSIOconnect method in
jderoot/java/src/jde/debugger/Application.java.
- Paul
>/mattias
