Re: JDEBug vs Win2K and/or NT4: Status?
- Original Message - From: "Javier Lopez" <[EMAIL PROTECTED]> To: "John L. Utz III" <[EMAIL PROTECTED]>; "Paul Kinnucan" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 08, 2001 2:33 PM Subject: RE: JDEBug vs Win2K and/or NT4: Status? > 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. > I agree with Javier. I believe the problem is that JDEbug is able to start the socket but is unable to to report the port number back to Emacs/JDE, either because the thread that creates the socket (and reports the port number) is blocked or because JDEbug's standard out buffer is not being flushed for some reason. - Paul
RE: JDEBug vs Win2K and/or NT4: Status?
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 p
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/xerces_1_0_3/xerces.jar;s:/java/jars/Xalan/xalan.jar;s:/java/jars/toplink/TOPLink.jar;s:/java/jars/toplink/Tools.jar;s:/java/jars/toplink/TOPLinkX.jar;s:/java/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 Emac
RE: JDEBug vs Win2K and/or NT4: Status?
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 s
RE: JDEBug vs Win2K and/or NT4: Status?
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 > > > > > >
Re: JDEBug vs Win2K and/or NT4: Status?
At 12:44 PM 4/27/01 -0400, you wrote:
>I could be wrong, but shouldn't it be using the port information from the
>connected socket (the results of the select) instead of the port from the
>listen/server socket?
I'm sorry I don't understand your point. Here is the code for the connection.
public int initConnect() throws JDEException {
jde.signal(procID, MESSAGE, "initSIOConnect: starting standard I/O
handshake.");
ServerSocket ss = null;
try {
ss = new ServerSocket(0);
} catch (IOException ex) {
throw new JDEException("Unable to create a server socket");
}
final ServerSocket sstmp = ss;
final int port = ss.getLocalPort();
standardIOConnectThread = new Thread("Standard I/O Thread for App
#"+procID) {
public void run() {
try {
jde.signal(procID, MESSAGE, "Debugger waiting for Emacs to connect to
app SIO port " +
port + ".");
sstmp.setSoTimeout(15);
sioSocket = sstmp.accept();
sstmp.close();
initTransport();
} catch (IOException ex) {
jde.signal(procID, ERROR, "IOException occurred while connecting to
app SIO port " + port +
". Shutting down...");
proc.shutdown();
} catch (SecurityException ex1) {
jde.signal(procID, ERROR, "Security exception occurred while
connecting to app SIO port " +
port);
}
}
};
jde.signal(procID, MESSAGE, "initSIOConnect: starting SIO connect
thread.");
standardIOConnectThread.start();
return port;
}
>
>You might try having it return sioSocket.getLocalPort(), which should never
>be wrong. To try to trace it, you could also log the sstmp.getLocalPort()
>and sioSocket.getLocalPort() either all the time or only when they are
>different.
>
As you can see, it does invoke getLocalPort() to get the port number of the
ServerSocket created by Java.
- Paul
>Just a thought.
>
>Martin
>
>ps. I was going to try out the above, but I wasn't easily able to get the
>environment right for building. When I have a little more time, I'll see if
>I can do it. Or, if you make the change and send me the jar file, I'll give
>it a spin and see what happens.
>
>- Original Message -
>From: "Paul Kinnucan" <[EMAIL PROTECTED]>
>To: "Javier Lopez" <[EMAIL PROTECTED]>; "Jim Goodwin"
><[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>Sent: Friday, April 27, 2001 11:48 AM
>Subject: RE: JDEBug vs Win2K and/or NT4: Status?
>
>
>> 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
RE: JDEBug vs Win2K and/or NT4: Status?
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 > >
Re: JDEBug vs Win2K and/or NT4: Status?
Title: JDEBug vs Win2K and/or NT4: Status? The timeout problem still happens to me on Windows 2000 SP1. It does not happen on Windows 2000 without SP1. In the Messages buffer: No response to command 1. (process = 1; timeout = 30 sec.) At this point, it's pretty much dead. There is a javaw process running, but my application is not. Even after exiting Emacs, the javaw process remains behind as an orphan Martin Martin Dickau, ByAllAccounts[EMAIL PROTECTED] - Original Message - From: Jim Goodwin To: '[EMAIL PROTECTED]' Sent: Friday, April 27, 2001 10:54 AM 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
RE: JDEBug vs Win2K and/or NT4: Status?
Title: JDEBug vs Win2K and/or NT4: Status? 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.0JVM Debug Interface version 1.0JVM 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 Javier -Original Message-From: Jim Goodwin [mailto:[EMAIL PROTECTED]]Sent: Friday, April 27, 2001 10:55 AMTo: '[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
