Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 123118

Summary: Cannot connect to VM
Product: [Eclipse Project] JDT Reporter: zhuge <zhuge>
Component: DebugAssignee: JDT-Debug-Inbox <jdt-debug-inbox>
Status: CLOSED INVALID QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert
Version: 3.1   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:

Description zhuge CLA 2006-01-09 11:23:04 EST
When I run the Java program, there is no error. But When I debug it as Java
Application, the error, Cannot connect to VM, occurs. Why? Please help me!

Thank you very much.

zhuge < zhuge@Rinaix.cn >
Comment 1 Michael Rennie CLA 2006-01-09 12:45:04 EST
*** Bug 123033 has been marked as a duplicate of this bug. ***
Comment 2 zhuge CLA 2006-01-09 12:52:18 EST
(In reply to comment #1)
> *** Bug 123033 has been marked as a duplicate of this bug. ***
> 

Thank you for your reassigning. Now I past the .log's information about it below.
!SESSION 2006-01-08 23:35:08.819 -----------------------------------------------
eclipse.buildId=I20050401-1645
java.fullversion=GNU libgcj 4.0.0 20050519 (Red Hat 4.0.0-8)
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=zh_CN Command-line arguments:  -os linux -ws gtk -arch x86 -data /home/zhuge/workspace
 !ENTRY org.eclipse.jdt.launching 4 120 2006-01-08 23:37:05.890
!MESSAGE Cannot connect to VM
!STACK 0
com.sun.jdi.connect.TransportTimeoutException
   at org.eclipse.jdi.internal.connect.SocketTransportService.accept(com.sun.jdi.connect.spi.TransportService$ListenKey, long, long) (/usr/lib/eclipse/plugins/org.eclipse.jdt.debug_3.1.0/jdimodel.jar.so)
   at org.eclipse.jdi.internal.connect.SocketTransportImpl.accept(long, long) (/usr/lib/eclipse/plugins/org.eclipse.jdt.debug_3.1.0/jdimodel.jar.so)
   at org.eclipse.jdi.internal.connect.SocketListeningConnectorImpl.accept(java.util.Map) (/usr/lib/eclipse/plugins/org.eclipse.jdt.debug_3.1.0/jdimodel.jar.so)
   at org.eclipse.jdt.internal.launching.StandardVMDebugger$ConnectRunnable.run() (/usr/lib/eclipse/plugins/org.eclipse.jdt.launching_3.1.0/launching.jar.so)
   at java.lang.Thread.run() (/usr/lib/libgcj.so.6.0.0)

 Thank you very much.

zhuge < zhuge@Rinaix.cn >
Comment 3 Darin Wright CLA 2006-01-09 14:32:50 EST
What is your launch timeout preference value set to on the "Java > Debug" preference page?
Comment 4 zhuge CLA 2006-01-09 15:15:19 EST
(In reply to comment #3)
> What is your launch timeout preference value set to on the "Java > Debug"
> preference page?
> 

The launch timeout is 20000 and the debugger timeout is 3000.
Comment 5 Darin Wright CLA 2006-01-11 08:52:27 EST
The launch timeout is used when attempting to connect to a VM (i.e. 20 seconds in this case). Does it actually take 20 seconds for the failure notification to occurr after pressing "debug"?
Comment 6 Darin Wright CLA 2006-01-18 11:11:18 EST
*** Bug 123402 has been marked as a duplicate of this bug. ***
Comment 7 Darin Wright CLA 2006-01-18 11:11:36 EST
Do you have a firewall turned on? If so, try with the firewall off.
Comment 8 zhuge CLA 2006-01-21 14:29:23 EST
(In reply to comment #7)
> Do you have a firewall turned on? If so, try with the firewall off.
> 

I have tried do debugging at least 100 times with the firewall off. But the bug, "Cannt connect to VM", also exists. Why? Why? ... Why? I will be mad! My machine's OS is Fedora Core 4 (FC4) and its locale is Chinese. Did you try with like this OS? I DO think it also occurs "Cannt connect to VM". Maybe Eclipse does NOT fit  on Linux, such as Red Hat Linux, Fedora Core, Free BSD, and so on. While Eclipse ONLY runs on DOS such as Microsoft Windows.
Comment 9 Kevin Barnes CLA 2006-01-23 10:14:14 EST
What VM are you using?
Every build of Eclipse is test on linux (over 500 unit tests) and members of the debug team develop on linux as well as windows and MacOS X. None of us use chinese OS's however.
Comment 10 zhuge CLA 2006-01-23 14:30:29 EST
(In reply to comment #9)
> What VM are you using?
> Every build of Eclipse is test on linux (over 500 unit tests) and members of
> the debug team develop on linux as well as windows and MacOS X. None of us use
> chinese OS's however.
> 

I use 1.4.2 VM. In fact, if you have used the Fedora Core 4 (FC4),  you should know  the VM. Also, from what I bugged (or commented) before, you could know the VM I use. And in fact, the bug also occurs on any locale besides Chinese. Can you know the Red Hat Fedora Core OS? Please try again and then fix the bug.
Comment 11 Kevin Barnes CLA 2006-01-23 14:41:58 EST
You're right, if I'd looked more carefully I could have shut down this bug w/o asking any more questions. Sorry.
GCJ is not a VM supported by Eclipse.
Marking INVALID.
Comment 12 zhuge CLA 2006-01-24 08:02:46 EST
(In reply to comment #11)
> You're right, if I'd looked more carefully I could have shut down this bug w/o
> asking any more questions. Sorry.
> GCJ is not a VM supported by Eclipse.
> Marking INVALID.
> 
However, the GCJ is published by GNU, the outstanding Free Software Foundation, and the Linux kernel is published by GNU.  I think that it is useful-less if one IDE can NOT provide debugging and it is NO meaning if one tool is NOT compatible for Linux (GNU) or is supported by GNU (Linux). Do you think so? Then I NEED your HELP. How can I do for using the Eclipse on GNU Linux in which the GCJ is built, such as Red Hat Linux, Fedora Core? Please tell me how to do. Please help me!

The YUM (Yellowdog Updater Modified for RPM) tool of my OS is activated to often  update the packages including Eclipse. From the following .log's message, I can know the build of Eclipse on my sysytem is 3.1.1.

!SESSION 2006-01-24 02:42:53.201 -----------------------------------------------
eclipse.buildId=M20050929-0840
java.fullversion=GNU libgcj 4.0.2 20051125 (Red Hat 4.0.2-8)
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=zh_CN
Command-line arguments:  -os linux -ws gtk -arch x86

!ENTRY org.eclipse.jdt.launching 4 120 2006-01-24 02:46:48.558
!MESSAGE Cannot connect to VM
!STACK 0
com.sun.jdi.connect.TransportTimeoutException
   at org.eclipse.jdi.internal.connect.SocketTransportService.accept(com.sun.jdi.connect.spi.TransportService$ListenKey, long, long) (/usr/lib/gcj/eclipse/jdimodel.jar.so)
   at org.eclipse.jdi.internal.connect.SocketTransportImpl.accept(long, long) (/usr/lib/gcj/eclipse/jdimodel.jar.so)
   at org.eclipse.jdi.internal.connect.SocketListeningConnectorImpl.accept(java.util.Map) (/usr/lib/gcj/eclipse/jdimodel.jar.so)
   at org.eclipse.jdt.internal.launching.StandardVMDebugger$ConnectRunnable.run() (/usr/lib/gcj/eclipse/org.eclipse.jdt.launching_3.1.0.jar.so)
   at java.lang.Thread.run() (/usr/lib/libgcj.so.6.0.0)
Comment 13 Darin Wright CLA 2006-01-24 09:03:07 EST
The Java debugger in Eclipse works using the JPDA standard (via JDI/JDWP) - see http://java.sun.com/j2se/1.4.2/docs/guide/jpda/index.html. GCJ compiles to native and must be debugged with something like GDB - see http://gcc.gnu.org/java/faq.html#1_6.
Comment 14 Andrew Overholt CLA 2006-01-24 12:03:18 EST
JDWP support is being worked on for gij (the GNU java bytecode interpreter) and other GNU Classpath-using VMs.
Comment 15 zhuge CLA 2006-01-24 12:18:48 EST
(In reply to comment #13)
> The Java debugger in Eclipse works using the JPDA standard (via JDI/JDWP) - see
> http://java.sun.com/j2se/1.4.2/docs/guide/jpda/index.html. GCJ compiles to
> native and must be debugged with something like GDB - see
> http://gcc.gnu.org/java/faq.html#1_6.
> 
I suggest that you should fix the bug through contacting with RedHat.
I have reported the bug to RedHat. And the bug number is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178820  . Till now, they reply one comment. And the content is "There is no JDWP support (what Eclipse uses for debugging java bytecode) in gij yet.  It is being worked on."
Comment 16 Kevin Barnes CLA 2006-01-24 12:26:46 EST
This is not an Eclipse bug. It's a problem with gij. See comment #14.

The workaround is to download a java vm from Sun or IBM and download Eclipse from eclipse.org instead of using the version that you have.
Comment 17 zhuge CLA 2006-01-24 12:28:12 EST
(In reply to comment #14)
> JDWP support is being worked on for gij (the GNU java bytecode interpreter) and
> other GNU Classpath-using VMs.
> 

Then, how about NOT to use the JDWP?
Comment 18 Darin Wright CLA 2006-01-24 12:33:29 EST
This bug is closed. The java debugger uses the standard JPDA architecture so it can interact with many (majority) of VMs that support the standard.
Comment 19 zhuge CLA 2006-01-24 12:36:47 EST
(In reply to comment #16)
> This is not an Eclipse bug. It's a problem with gij. See comment #14.
> 
> The workaround is to download a java vm from Sun or IBM and download Eclipse
> from eclipse.org instead of using the version that you have.
> 

Thank you for your help. amoment ago, I recieved the RedHat reply. They say, "It's not a matter of working with the eclipse.org people.  It's just a matter of
getting JDWP support.  It's being worked on. "