View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000963||Xdebug||Uncategorized||public||2013-07-15 14:56||2013-12-03 00:13|
|Platform||Linux x86_64||OS||Ubuntu||OS Version||13.04|
|Fixed in Version||2.2.4|
|Summary||0000963: Xdebug wait response from remote client and hang up apache php mod|
I have Apache web server with setup php 5.4 module. Server run on Ubuntu 13.04 Server on VirtualBox vm. I work on PhpStrom 6.0.3 on Windows 8.
Only after that I can get response from server.
Config for xdebug in php.ini:
xdebug support => enabled
Supported protocols => Revision
Directive => Local Value => Master Value
|Steps To Reproduce|
|Tags||No tags attached.|
|Operating System||Uduntu 13.04 Server|
reproduce for me with config xdebug.remote_connect_back => On => On too.
Pretty sure this is what I was going to try to report as well.
If port 9000 is not available on the client machine, depending on how the network stack rejects it, PHP will stall out infinitely until the webserver timeout occurs.
For example, my desktop port 9000 instantly returns connection refused - that's fine.
A bunch of my coworkers' desktops port 9000 doesn't return back a connection refused. So it hangs there.
Perhaps adding in a "xdebug.remote_connect_back_timeout" variable would be nice? So it can be set to 1-2 seconds or maybe even make it use microseconds. Then it can gracefully timeout even if it's not getting a strict "connection refused" - otherwise it seems to stay open indefinitely until the webserver hangs up the FastCGI connection.
zend_extension = /usr/lib/php5/20100525/xdebug.so
PHP 5.4.17 from ondrej/php5-oldstable, Ubuntu 12.04.2 precise x86_64
I can not reproduce this myself. What I would need to debug this is to see a communication session with both strace and wireshark. Is that something you can get me?
I'm the developer of the Xdebug extension for Chrome/Safari and I got a issue report on Github that looks an awful lot like this issue reported here. See: https://github.com/mac-cain13/xdebug-helper-for-chrome/issues/37
Now I did some testing myself and it seems that mike503 is right about the connection rejection and how it relates to PHP scripts hanging.
So if something (non-Xdebug stuff) is listening on port 9000 or the firewall is in stealth mode blocking all trafiic and NOT explicitly refusing the connection Xdebug will stall the PHP script waiting for a timeout. The timeout will only happen after quite some time and render things unusable.
I think it would be great if you can update the Xdebug FAQ to state this so people can take action (change firewall ruled for example). Also the proposed "xdebug.remote_connect_back_timeout" would be great to make Xdebug continue after a few seconds if the connection won't succeed.
If you need more info/traces let me know, I'll see what I can do!
Not quite tested on Windows though!
|2013-07-15 14:56||alexey.bakulin||New Issue|
|2013-07-15 14:58||alexey.bakulin||Note Added: 0002536|
|2013-08-02 23:17||mike503||Note Added: 0002551|
|2013-10-09 18:37||derick||Note Added: 0002574|
|2013-10-14 00:32||derick||Assigned To||=> derick|
|2013-10-14 00:32||derick||Status||new => feedback|
|2013-11-26 23:04||mac_cain13||Note Added: 0002622|
|2013-12-03 00:13||derick||Note Added: 0002623|
|2013-12-03 00:13||derick||Status||feedback => closed|
|2013-12-03 00:13||derick||Resolution||open => fixed|
|2013-12-03 00:13||derick||Fixed in Version||=> 2.2.4|
|2014-02-27 19:21||derick||Relationship added||has duplicate 0000805|
|2016-07-31 12:36||derick||Category||Usage problems => Usage problems (Crashes)|
|2016-07-31 12:38||derick||Category||Usage problems (Crashes) => Usage problems (Wrong Results)|
|2020-03-12 16:35||derick||Category||Usage problems (Wrong Results) => Variable Display|
|2020-03-12 16:38||derick||Category||Variable Display => Uncategorized|