Posted: 2014-12-15 00:14:04
When NetBeans is unable to make a connection with XDebug, the NetBeans IDE will display message “Waiting For Connection (netbeans-xdebug)” at the bottom right corner…
Lets go through the list of things that can cause this issue.
* To save you all the reading, this issue is more than likely your firewall or anti-virus software blocking NetBeans from establishing a connection, or NetBeans attempting to connect with XDebug on something other than IP 127.0.0.1 (through a LAN or Public IP, or on the IPv6 interface) and port 9000.
After configuring XDebug and setting up NetBeans to use the same local web server, check the Project settings to make sure everything is correct:
After going over the above settings, also click the “Advanced…” button, and make sure that the listed port value is set on 9000.
Make sure XDebug has actually been loaded by PHP, and it’s settings are correct.
The important settings are these:
xdebug.remote_enable=1 xdebug.remote_handler=dbgp xdebug.remote_host=127.0.0.1 xdebug.remote_port=9000 xdebug.remote_autostart=0 xdebug.remote_connect_back=0
This tells XDebug to enable connections to it, and to send the data back to 127.0.0.1:9000, which hopefully NetBeans is listening on.
Check the specific website’s PHP error log file for any clues such as “unable to load module …” and “Call to undefined function …”.
Also check the general Apache and PHP error log files for the same messages or other errors.
* The PHP error log file will not exist if: you are using PHP-FCGI (in this case the errors are logged to each website’s individual PHP error log file), and/or no errors have been generated so far.
Does the URL http://www.example.com/ (substitute in your domain name) come up without any issues?
If not, then possibly:
Make sure NetBeans is closed, and restart Apache, don’t start NetBeans. Does the full query URL come up without any issues?
If not, then possibly:
NetBeans will use a URL with a query similar to this:
Possible .htaccess and VirtualHost mod_rewrite rules that use, parse, and/or redirect requests based on the query string could break the request.
Stop Apache, and delete all files in PHP’s and XDebug’s temporary folders:
This will clear out any previous sessions so you can start with a fresh PHP session store and a fresh XDebug data store. Sometimes these temp files get corrupted, or don’t get cleared out properly, and things get hung up.
Make sure that another process or program has not taken
Close NetBeans, stop Apache, wait a minute for all the Listeners to clear out, then open the command line (admin mode), and execute:
netstat -o -n -a | findstr 127.0.0.1:9000
If it finds a Local Address Listener (which is the 1st address, not the 2nd), you can cross-reference the PID (Process ID #) shown in Windows Task Manager, Processes Tab (click button: ‘Show processes from all users’ at bottom so it displays everything).
Whatever this turns out to be, it needs to be stopped and disabled, or re-configured to not take port 9000.
* The other option is to reconfigure both NetBeans and XDebug (php.ini) to use another port.
If the above is clear, verify that NetBeans is:
Start Apache, open NetBeans, load your project, make a debug point in the PHP code, and click to Debug it.
Once this is started, NetBeans should create the proper Listeners, and if everything is correct, start talking back and forth with Apache (if PHP is type:Regular) or PHP (if PHP is type: FCGI) between port 9000 and some random port of the Apache / httpd or PHP process…
netstat -o -n -a | findstr :9000
A good debugging connection between NetBeans and Xdebug looks like this:
TCP 0.0.0.0:9000 0.0.0.0:0 LISTENING 5424 TCP 127.0.0.1:9000 127.0.0.1:50821 ESTABLISHED 5424 TCP 127.0.0.1:50821 127.0.0.1:9000 ESTABLISHED 6604 TCP [::]:9000 [::]:0 LISTENING 5424
It shows that NetBeans (PID 5425) is Listening on all IPv4 addresses (0.0.0.0 includes 127.0.0.1), and that there is a connection Established to and from Apache / httpd (PID 6604).
* Names of processes are shown in Windows Task Manager, Processes Tab (click button: ‘Show processes from all users’ at bottom so it displays everything).
The important part here is that NetBeans is at least Listening on 0.0.0.0:9000. Otherwise, its settings are wrong, or something (usually firewall and anti-virus software) is preventing it from starting that Listener.
If NetBeans is not using the correct port (9000), update NetBeans settings:
Tools, Options, PHP, Debugger Port
Or update XDebug’s php.ini settings to match that port.
If there is no proper IPv4 (0.0.0.0:9000 or 127.0.0.1:9000) Listener, verify that:
NetBeans, and Java, have NOT been configured to prefer (use) IPv6 over IPv4:
For NetBeans –
Global Configuration File:
C:\Program Files\NetBeans 8.x.x\etc\netbeans.conf
Local Configuration File (might not exist):
In option “
netbeans_default_options” make sure it’s not set to prefer IPv6:
If it is, change it to:
For Java –
Control Panel - System - Advanced System Settings - System Properties - Advanced tab - Environment Variables
Check the environmental variables list for variable:
If it exists and contains:
Change it to:
Also open the Java Control Panel, and check if there are any Java Runtime Parameters (Java – View) or Proxy Settings (General – Network Settings) listed.
Control Panel - Java
* After these changes, reboot.
Make sure that NetBeans is working with IP 127.0.0.1, rather than the LAN IP or Public IP!
Otherwise, XDebug’s “
xdebug.remote_host=127.0.0.1” will need to either be updated with the specific IP, or “
xdebug.remote_connect_back=1” used to tell XDebug to connect back to ANY source IP…
“If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request. It checks the $_SERVER[‘REMOTE_ADDR’] variable to find out which IP address to use. Please note that there is no filter available, and anybody who can connect to the webserver will then be able to start a debugging session, even if their address does not match xdebug.remote_host.”
“When the URL variable XDEBUG_SESSION_START=name is appended to an URL Xdebug emits a cookie with the name “XDEBUG_SESSION” and as value the value of the XDEBUG_SESSION_START URL parameter.”
If there is an issue with cookies being set, “
xdebug.remote_autostart=1” must be used…
“Normally you need to use a specific HTTP GET/POST variable to start remote debugging. When this setting is set to 1, Xdebug will always attempt to start a remote debugging session and try to connect to a client, even if the GET/POST/COOKIE variable was not present.”
If the NetBeans project settings are correct, the website works in your Browser, and the IPv4 Listener is running, it is possible that your Firewall and/or Anti-virus software has decided to block:
A) The Java-based NetBeans program from making connections.
B) Apache (httpd) and PHP processes from making connections.
C) Port 9000 from being connected to.
You will have to either shut the Firewall and Anti-Virus applications off, or go through (and fix) their current lists of blocked and quarantined programs (NetBeans, Apache / httpd, PHP) and blocked ports (9000). Then create allow-rules and/or white-lists for NetBeans, Apache (httpd), PHP (php-fcgi), and port 9000.
I would start with McAfee and Kaspersky, by just turning them off (some of these don’t fully turn off and have to be uninstalled). Then check Windows Firewall the same way.
Also, just to cover the last bit, right-click on the php_xdebug.dll file, select Properties, and if it’s listed as “Blocked”, click to unblock it:
For best results while figuring out the cause of all this, to bypass all the external browsers, in the NetBeans Project’s Properties, Browser category, switch from ‘Default’ or ‘Chrome’ to “Embedded WebKit Browser”.
Some questions to ask yourself –
1. Have any other Apache or PHP extensions been loaded? Apache’s mod_security could easily block this (it’s never loaded by default in WampDeveloper Pro). Some extra PHP extensions might also conflict with XDebug.
2. Where there any changes made to PHP’s php.ini, aside from introducing the XDebug section? And also Apache’s configuration?
3. Has the website’s VirtualHost files been modified with php.ini overriding settings (“php_value” or “php_admin_value” setting “xdebug.remote_host=some.where.else”), other configurations, or access restriction?
4. Has the website’s .htaccess file been modified with php.ini overriding settings (as above), other configurations, or access restriction?
5. Where any extra .htaccess files placed into any of the parent folders (from the website), all the way up to C:\ ?