| Summary: | Cannot connect to VM | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | zhuge <zhuge> |
| Component: | Debug | Assignee: | 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
*** Bug 123033 has been marked as a duplicate of this bug. *** (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 > What is your launch timeout preference value set to on the "Java > Debug" preference page? (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. 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"? *** Bug 123402 has been marked as a duplicate of this bug. *** Do you have a firewall turned on? If so, try with the firewall off. (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. 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. (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. 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. (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) 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. JDWP support is being worked on for gij (the GNU java bytecode interpreter) and other GNU Classpath-using VMs. (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." 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. (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? 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. (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. " |