Community
Participate
Working Groups
Error message on console: FATAL ERROR in native method: No transports initialized Transport dt_socket failed to initialize, rc = 509. the reason for this is, that /jdk/bin directory does not contain dt_socket.dll steps to reproduce: make sure the dt_socket.dll is not in the system path configure a jdk as default in preferences->java->installed jres try to debug a java project that uses this default jdk workarounds: * add dt_socket.dll to system path (does not work if you use different jres (like me, i run my desktop apps on java6.0 which is in the path, but develop for 1.4)) * configure a jre as default instead of a jdk * copy dt_socket.dll from jdk/jre/bin to jdk/bin I like non of these workarounds. It should be possible to setup a jdk in the preferences and have eclipse use the jre dir inside to run projects. if you need more details, just ask. ps. this is the cause for bug#69262 , please don't close it as duplicate.
i just found this related bug: bug#128605 this may be a duplicate of that but, leaving it open because i only use sun vms and bug#128605 talks about using an ibm vm. ps. moved this to jdt-debug
I got the same problem. My eclipse works on jdk1.5.0_10 But my project shold work on 1.4.2. The project jdk is jdk1.4.2_13. The "Run As" Java Application menu creates a run task for jdk1.5. I see it on the used swing library and at the PATH property at the Environment of the Run dialog. So the debugger loads the wrong dt_socket.dll. If I change the PATH to the correct jdk, the debugging works fine.
I confirm this bug. Eclipse 3.3M6 running on Sun JDK 1.6u1, attempting to debug programs running on IBM JDK 1.4.2, all on Windows XP. Workaround #3 (using the IBM JRE inside the JDK) seems to work. I think the severity should be at least major, not normal, since this disables all debugging and it's not trivial to see the cause. Thanks Carl-Eric
for some reason, this bug is still assigned to pdt-debug. As i don't have the right to change the assignee, can someone please change it to 'jdt-debug-inbox' or give an advice how to move this bug there? I'm not sure about rising the severity to major as suggested in comment#3, but i agree that its very bad from a user experience point of view and might give inexperienced users a very hard time to solve it. regards, Dominik ps. Sorry for the assign inconveniece, i promise to read the bugzilla manual sometime soon.
I'm running in 3.3M6 with Jdk6, is there a working workaroud. I've tried all those in comments, but, they don't work.
Regarding the original bug report, if I launch Eclipse with a JDK, it does detect the JRE installtaion and debugging works. There are issues regarding debugging on jdk1.4.x when running the host on 1.5 or 1.6. Bug will be updated shortly with information.
The problem arrives when you have a vm installed (via windows installer or the like) and you would like to use an alternate vm for debugging or you have a path variable pointing to 1.6 and try to debug using 1.5 or 1.4. To reproduce, I installed java 1.6 (via the windows installer), and then downloaded some alterate JDKs (1.4.2-13 and 1.5-11) and placed them in a vms dir. I then started eclipse (on the 1.6 vm) and added all of my jdks to the installed jres page. That done I created a trvial helloworld program and tried to debug it: 1. using the default VM (1.6) <works fine> 2. using 1.5 <works fine> 3. using 1.4 <dt_socket error> More specifically the cause of this problem is that the target program is trying to find the required dll's in the dir of the installed jdk (in this case 1.6), so when a 1.4 vm tries to use dt_socket.dll from a 1.6 vm, it dies with the error given in comment 1. At this time there are a few workarounds as described here: http://forum.java.sun.com/thread.jspa?threadID=160025&start=15&tstart=0 To paraphrase: 1. copy the dt_socket and dt_shmem dlls to the respective jdk dir of their locations 2. change your PATH variable everytime to point to the right locations 3. create an environment variable for the associated launch configuration to set the desired PATH (in the launch dialog). We might be able to mod-up the correct environment at runtime, but it would likely involve us prepending the corrected JRE path to the environment that we pass into Runtime.exec(..). No modification would occur to the orginal path or any system variables on the users system, changes could only be made 'on the fly' as they are starting a debug session.
fixed in HEAD On windows platforms only, when compiling the command line, etc to launch a given program, we 'correct' the PATH variable to be prepended with the jre bin directory of the chosen installed vm. We DO NOT modify the original path variable in any way, and the lifecycle of the 'corrected' PATH variable is that of the program being launched. I tested this fix having a SUN 1.6 VM installed on my windows box (via a windows installer), SUN 1.4, 1.5, 7 and IBM 1.4, 1.5, 1.6 extracted to a vms folder.
please verify Darin W
Verified. Made the code more efficient - only one pass over the environment rather than 2.
*** Bug 136215 has been marked as a duplicate of this bug. ***
*** Bug 128605 has been marked as a duplicate of this bug. ***
*** Bug 199452 has been marked as a duplicate of this bug. ***
