hi John,
I don't know if hard coding the number is the best solution.
I was looking at this problem last week, let me tell you what I found.
I tried starting the JDEBug process outside the JDE and I still got the same
problem. The problem in question is that the process for some mysterious
reason is not showing all the output that the debugger is sending. If you
send and EOF signal in the buffer that contains the process
the missing output shows up but the EOF kills the
process. The next thing I was going to do was to check if the java
code was flushing all the output that was sending to the process.
Javier
-----Original Message-----
From: John L. Utz III [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 1:01 PM
To: Paul Kinnucan
Cc: [EMAIL PROTECTED]
Subject: RE: JDEBug vs Win2K and/or NT4: Status?
hi paul;
i have time to work on this again over the next few days....
here is the current error message with beta11 on my win2k sp1 box
*** Debugger Output for Process com.singingfish.cpp.apps.xmlValidator(2)
***
Launched VM Java Debug Interface (Reference Implementation) version 1.3
Java Debug Wire Protocol (Reference Implementation) version 1.0
JVM Debug Interface version 1.0
JVM version 1.3.0_01 (Java HotSpot(TM) Client VM, interpreted mode)
initSIOConnect: starting standard I/O handshake.
initSIOConnect: starting SIO connect thread.
Debugger waiting for Emacs to connect to app SIO port 3527.
vm started...
All threads suspended...
Launch command line:
javaw -classpath
u:/dest_classpath;s:/java/jars/jdbc2_0-stdext/lib/jdbc2_0-stdext.jar;s:/java
/jars/jta-spec1_0_1/jta-spec1_0_1.jar;s:/java/jars/jndi1_2_1/lib/jndi.jar;s:
/java/jars/ldap1_2_1/lib/providerutil.jar;s:/java/jars/rmiregistry1_2_1/lib/
rmiregistry.jar;s:/java/jars/oracle_jdbc/lib/classes12.zip;s:/java/jars/xerc
es_1_0_3/xerces.jar;s:/java/jars/Xalan/xalan.jar;s:/java/jars/toplink/TOPLin
k.jar;s:/java/jars/toplink/Tools.jar;s:/java/jars/toplink/TOPLinkX.jar;s:/ja
va/jars/PerlTools-1.2.0a/PerlTools.jar;s:/java/jars/servlet1_2_2/servlet.jar
;s:/java/jars/oracle_aq/aqapi.jar;s:/java/jars/aimie_1_0_0/aimie.jar;s:/java
/jars/junit3_5/junit.jar;s:/java/jars/oreilly_1_0_0/oreilly.jar;s:/java/jars
/javamail_1_1_3/mail.jar;s:/java/jars/quicktime_4_1/QTJava.zip;s:/java/jars/
jaf_1_0_1/activation.jar;s:/java/jars/ant_1.3
com.singingfish.cpp.apps.xmlValidator
Emacs connected to standard IO port 3526 for process
com.singingfish.cpp.apps.xmlValidator.
Gave up waiting for Emacs to connect to SIO port: 3527
so, which el file do i brutally hack to hardcode the port number? :-)
i poked around in jde-db.el and jde-bug.el, but i didnt see anything
pertinent. so i decided to give up and ask.
i *really* want to make progress on this!
tnx!
johnu
On Fri, 27 Apr 2001, Paul Kinnucan wrote:
> Hi John,
>
> I think you are on to something here. I failed to notice that Javier tried
> to launch a debuggee process twice in succession. Apparently JDE failed to
> get the message to connect to port 1900 on the first attempt, perhaps
> because standard I/O was blocked. On the second attemp, the message from
> the first attempt finally reaches the JDE and the JDE connects to socket
> 1900. Meanwhile JDEbug has created another socket 1901 and has sent a
> message to connect to that socket to the JDE. Again this second never
> message never reaches the JDE and thus JDE never attempts to connect to
the
> socket and eventually the socket times out, resulting in the "gave up
> waiting" message for JDEbug.
>
> I think the problem may be figuring out what is blocking the JDE from
> getting the socket message from JDEbug. Another approach may be just to
cut
> the Gordian knot and abandon the whole idea of having the operating system
> assign a port. Rather, the JDE can include a predetermined (but
> configurable) port number in the launch process command to JDEbug. For
> example, the default port might by 5656. So JDE would pass this port
number
> ot JDEbug, wait a little while to give JDEbug time to launch the
> application and set up a socket, and then attempt to connect to port 5656,
> assuming that JDEbug has had time to create a server socket at 5656.
>
> - Paul
>
>
> At 11:54 AM 4/27/01 -0700, you wrote:
> >Wild guess made without looking at the code:
> >
> >it may be trying to connect twice because it somehow didnt get hooked up
> >with the successful java connection to port 1900.
> >
> >so java has sucessfully engaged port 1900 and is patiently waiting there.
> >
> >JDEbug may have timed out and attempted to reconnect. but it's discovered
> >that there is 'some guy' on port 1900 so it tries to get java to start up
> >with 1901.
> >
> >java sees no reason to honor the request because it's already busy
waiting
> >on 1900.
> >
> >thus, two lonely ships pass in the night :-)
> >
> >
> >again, this is just a guess.
> >
> >On Fri, 27 Apr 2001, Paul Kinnucan wrote:
> >
> >> At 11:10 AM 4/27/01 -0400, Javier Lopez wrote:
> >> >
> >> > I tried it on simple class, (JDE->Debug App)
> >> > and I get something like
> >> > Error: debugger didn't respond to command:
> >> > -1 2607 launch 12 -vmexec javaw -classic
> >> >
> >> > or something like
> >> > No response to command 2612. (process = 13; timeout = 30 sec.)
> >> >
> >> > But the most intersting one is this one.
> >> > this JDE->Debug App wait for it to fail and repeat JDE-Debug App
> >> >
> >> > *** Debugger Output for Process Test(2) ***
> >> >
> >> > Launched VM Java Debug Interface (Reference Implementation) version
1.3
> >> > Java Debug Wire Protocol (Reference Implementation) version 1.0
> >> > JVM Debug Interface version 1.0
> >> > JVM version 1.3.0_01 (Classic VM, native threads, nojit)
> >> > initSIOConnect: starting standard I/O handshake.
> >> > initSIOConnect: starting SIO connect thread.
> >> > Debugger waiting for Emacs to connect to app SIO port 1901.
> >> > vm started...
> >> > All threads suspended...
> >> > Launch command line:
> >> > javaw -classic Test c:/code/Development/src/ config
> ConfigVariables.vars
> >> > tmpl
> >> >
> >> > Emacs connected to standard IO port 1900 for process Test.
> >> > VM options: '-classic '
> >> > Gave up waiting for Emacs to connect to SIO port: 1901
> >> >
> >>
> >>
> >>
> >> Wow! Putting a timout on the socket accept process in JDE-2.2.7beta11
really
> >> paid off. I should have done this ages ago. It appears that for some
reason
> >> Emacs and Java are off by 1 on the socket number. This is the first
solid
> >> information I've gotten on this problem in about a year and would
> explain the
> >> hangup. Now the question is why the difference? I can't look at this
right
> >now
> >> but if anyone else wants to pursue it, here is some background. One of
the
> >> steps performed by JDEbug when launching an application is to create a
> server
> >> socket. JDEbug allows Java to choose the port number of the server
socket
> >> (e.g., 1900). JDEbug then sends this port number back to the JDE. The
JDE
> >then
> >> triees to connect to the socket on the specified port. What appears is
that
> >> somehow, on some systems, the port number gets bumped by 1 so that
> JDEbug is
> >> waiting on port 1901 while the JDE is trying to connect to port 1900.
> >>
> >> Any thoughts as to why this might be happening?
> >>
> >> - Paul
> >>
> >> >
> >> > Javier
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Jim Goodwin [mailto:[EMAIL PROTECTED]]
> >> > Sent: Friday, April 27, 2001 10:55 AM
> >> > To: '[EMAIL PROTECTED]'
> >> > Subject: JDEBug vs Win2K and/or NT4: Status?
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I see in the mail-traffic that Paul K has changed the JDEBug code to
> >avoid
> >> >> setting priority on the thread when launching the debuggee process,
in
> >an
> >> >> effort to cure the problems with deadlocking at launch.
> >> >>
> >> >> What has not appeared is any user report of whether this has helped
or
> >> >> cause the problems to go away. Has anyone tried this yet with Win2K
> >> >> and/or NT 4? And if so, what experience have y'all had?
> >> >> jim
> >> >
> >> >
> >>
> >>
>
>
