Eclipse能Run不能Debug官方解决办法（亲测可用）

I can run a program but not debug it???

This problem happens quite often where a user can run a program, but as soon as they try to debug it they get errors about 'unable to connect' or even more nasty looking ones like: 

    FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=JVMTI_ERROR_INTERNAL(113)
    ERROR: transport error 202: gethostbyname: unknown host ["transport.c",L41]
    ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
      ["debugInit.c",L500]
    JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initialized

99% of the time, the problem is just a simple misconfiguration of either the users' computer or the configuration to be launched.

Here are some of the solutions to the 'run but not debug' problem

1. Check if you computer has a firewall. If it does make sure that eclipse has TCP access to 'localhost', as the debugger uses TCP to communicate with the target VM. Note: there are no port ranges, as the platform Eclipse debugger scans for the first available port to use, there is no set range it will choose from.
2. If you are using Linux, check that your hosts file, located in /etc/hosts, has a correct mapping for 'localhost'. If there is no mapping for 'localhost' than the debugger cannot resolve connecting to the local VM via TCP. Following is an example of a hosts file with a correct mapping. 
   

         # Do not remove the following line, or various programs
         # that require network functionality will fail.
         ::1     localhost.localdomain   localhost
         127.0.0.1   localhost
      

   See this bug if you are running debian testing/squeeze: [[1]]

3. If you edit the launching environment (via the 'Environment' tab in the launch dialog) and have selected to 'replace my environment', you must ensure that the variables you specify as replacements are sufficient for launching. More specifically, you have to include all of the environment variables that your system and Eclipse needs to launch. The safest course of action when you want select the 'replace my environment' is to add all of the variables and your own, and to only remove those which you know for a fact are not required by your system or Eclipse.
4. It could be that there is some garbage text in your environment. To find out try typing either

   cmd.exe /C set (in Windows)

   or

   env (in Linux or Mac)

   . The output produced should look like the following, where there are variables followed by an '=', followed by the value of the variable.

      PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/VMs/SUN-1.6.0_01/bin:/root/bin
      GDM_XSERVER_LOCATION=local 
      INPUTRC=/etc/inputrc
      JAVA_HOME=/VMs/SUN-1.6.0_01 
      LANG=en_CA.UTF-8 
      GDM_LANG=en_CA.UTF-8
      GDMSESSION=default
      HOME=/root
      ...
   

   If there is garbage text in this output you need to clean up your system variables, otherwise the debugger cannot parse your environment. The other solution to this is to migrate to using Eclipse 3.3.1 or newer, where we added support for ignoring garbage text in your environment.
5. If you have the JRE you wish to use for launching installed in a jdk path, the debugger will not start complaining about its inability to find system libraries. For example, lets say you have Java 6 installed in C:\java\jdk6. Now lets say that in Eclipse you have your default JRE (the one you want to use for launching) set to the installed path C:\java\jdk6. Pre-3.3.1 debugging will not work because we would scan the current directory to find the system libraries needed to debug, and find none. The problem was that we were not correctly appending paths in our debugger to find the system libraries in the JRE folder of the install location. This has been fixed in Eclipse 3.3.1.