P4
FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode)
Confirmed for Mustang:
java version "1.6.0-beta2"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-b84)
Java HotSpot(TM) Client VM (build 1.6.0-beta2-b84, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Linux notebook 2.6.15-gentoo-r1 #1 Sat Feb 18 14:55:49 CET 2006 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz GNU/Linux
EXTRA RELEVANT SYSTEM CONFIGURATION :
Network Interfaces:
lo is set up as usual for loopback using 127.0.0.1
eth0 is dynamic address by DHCP and default route
eth1 would be some local net, but is unavailable at the moment.
/etc/hosts configuration
localhost is 127.0.0.1
my local host name corresponds to the address on eth1 which is not available at the moment
A DESCRIPTION OF THE PROBLEM :
When starting the debugger with the above configuration, it hangs for some time waiting for a timeout, and then aborts. The reason is that the hostname of the local machine is used to derive an IP address. Instead it should use the name "localhost" or the loopback IP 127.0.0.1.
There might be other situations when a loopback connection would be better than a connection using the host name. One is firewall rules on the other network interface(s). A second is security considerations (see 4717237).
The more special bugs 5096347, 4969312 could probably be solved by this generic improvement as well.
The not jdb related problem of what InetAddress.getLocalHost should return is discussed in bug 4665037. But changing that might take some time, while switching jdb to a hardcoded 127.0.0.1 should be fairly easy.
It seems to be already implemented as a fallback at least in mustangs com.sun.tools.jdi.SocketTransportService. So simply make it the default, and check it is bound to some network interface as well if you want to be sure.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. find out your hostname
2. look up that hostname in /etc/hosts
3. bring down the interface associated with that IP
4. start jdb locally
5. run
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
jdb running, communicating with the started VM using the loopback network device lo
ACTUAL -
$ jdb -classpath dst -sourcepath src the.main.Class
Initializing jdb ...
> run
run the.main.Class
Then some minutes waiting for the timeout, before the error message comes:
ERROR MESSAGES/STACK TRACES THAT OCCUR :
VM start exception: VM initialization failed for: /opt/sun-jdk-1.5.0/jre/bin/java -classpath dst -Xdebug -Xrunjdwp:transport=dt_socket,address=notebook:47114,suspend=y the.main.Class
ERROR: transport error 202: connect failed: Connection timed out ["transport.c",L41]
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) ["debugInit.c",L497]
JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initializedFATAL ERROR in native method: JDWP No transports initialized, jvmtiError=JVMTI_ERROR_INTERNAL(113)
Fatal error:
Target VM failed to initialize.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
1. edit /etc/hosts or have DHCP daemon do this
2. bring up the necessary interface
3. Build up some remote debugging scenario
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode)
Confirmed for Mustang:
java version "1.6.0-beta2"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-b84)
Java HotSpot(TM) Client VM (build 1.6.0-beta2-b84, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Linux notebook 2.6.15-gentoo-r1 #1 Sat Feb 18 14:55:49 CET 2006 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz GNU/Linux
EXTRA RELEVANT SYSTEM CONFIGURATION :
Network Interfaces:
lo is set up as usual for loopback using 127.0.0.1
eth0 is dynamic address by DHCP and default route
eth1 would be some local net, but is unavailable at the moment.
/etc/hosts configuration
localhost is 127.0.0.1
my local host name corresponds to the address on eth1 which is not available at the moment
A DESCRIPTION OF THE PROBLEM :
When starting the debugger with the above configuration, it hangs for some time waiting for a timeout, and then aborts. The reason is that the hostname of the local machine is used to derive an IP address. Instead it should use the name "localhost" or the loopback IP 127.0.0.1.
There might be other situations when a loopback connection would be better than a connection using the host name. One is firewall rules on the other network interface(s). A second is security considerations (see 4717237).
The more special bugs 5096347, 4969312 could probably be solved by this generic improvement as well.
The not jdb related problem of what InetAddress.getLocalHost should return is discussed in bug 4665037. But changing that might take some time, while switching jdb to a hardcoded 127.0.0.1 should be fairly easy.
It seems to be already implemented as a fallback at least in mustangs com.sun.tools.jdi.SocketTransportService. So simply make it the default, and check it is bound to some network interface as well if you want to be sure.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. find out your hostname
2. look up that hostname in /etc/hosts
3. bring down the interface associated with that IP
4. start jdb locally
5. run
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
jdb running, communicating with the started VM using the loopback network device lo
ACTUAL -
$ jdb -classpath dst -sourcepath src the.main.Class
Initializing jdb ...
> run
run the.main.Class
Then some minutes waiting for the timeout, before the error message comes:
ERROR MESSAGES/STACK TRACES THAT OCCUR :
VM start exception: VM initialization failed for: /opt/sun-jdk-1.5.0/jre/bin/java -classpath dst -Xdebug -Xrunjdwp:transport=dt_socket,address=notebook:47114,suspend=y the.main.Class
ERROR: transport error 202: connect failed: Connection timed out ["transport.c",L41]
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) ["debugInit.c",L497]
JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initializedFATAL ERROR in native method: JDWP No transports initialized, jvmtiError=JVMTI_ERROR_INTERNAL(113)
Fatal error:
Target VM failed to initialize.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
1. edit /etc/hosts or have DHCP daemon do this
2. bring up the necessary interface
3. Build up some remote debugging scenario