MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001470XdebugRemote Debuggingpublic2017-09-12 08:472017-12-02 18:36
Reportermatt 
Assigned Toderick 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformPHP 7.0OSUbuntuOS Version16.04
Product Version2.5.1 
Target Version2.6.0Fixed in Version2.6.0alpha1 
Summary0001470: Make connect timeout configurable (now 200ms)
DescriptionI have an issue with starting remote session with a distant server. Using
tcpdump 'port 9000'
on the remote server this is what I see:

15:26:56.016599 IP XXX.XXX.XXX.XXX.46162 > YYY.YYY.YYY.YYY.9000: Flags [S], seq 2569969333, win 29200, options [mss 1460,sackOK,TS val 3777227854 ecr 0,nop,wscale 7], length 0
15:26:56.413753 IP YYY.YYY.YYY.YYY.9000 > XXX.XXX.XXX.XXX.46162: Flags [S.], seq 3524664740, ack 2569969334, win 65535, options [mss 1440,nop,wscale 8,sackOK,TS val 1887139287 ecr 3777227854], length 0
15:26:56.413885 IP XXX.XXX.XXX.XXX.46162 > YYY.YYY.YYY.YYY.9000: Flags [R], seq 2569969334, win 0, length 0

So the reset is done immediately after SYN from my IDE. In remote log I see:

Log opened at 2017-09-11 18:54:08
I: Connecting to configured address/port: YYY.YYY.YYY.YYY:9000.
E: Time-out connecting to client. :-(
Log closed at 2017-09-11 18:54:08

Browsing through XDebug code I stumbled on this in xdebug/xdebug_com.c:
int xdebug_create_socket(const char *hostname, int dport TSRMLS_DC)
{
[...]
int timeout = 200;
[...]
sockerror = poll(ufds, 1, timeout);
[...]
/* A timeout occured when polling the socket */
if (sockerror == 0) {
    sockerror = SOCK_TIMEOUT_ERR;
    break;
}
[...]

SOCK_TIMEOUT_ERR is '-2' and triggers the "Time-out connecting to client" message in log.

So, there seems to be a 200 ms limit for connection to be made. Unfortunately the remote server I'm dealing with has ping of 400ms+ to my machine, which prevents me from using remote debugging. According to man page poll returns '0' when there are no events for any of passed sockets and it's not an error for this to happen.

Can we please either increase the timeout to something 'that surely should be enough' (on Earth) or better yet make it configurable (to make it future proof in case we have to debug a server on Moon)? This hopefully should be a minor fix?

I realize the session would be pretty sluggish anyway, but there are cases when some bugs happen only on particular machine on the other side of the world and no one knows why and remote debugging is only easy and sane option.
Steps To ReproduceUhm.. Use tc for traffic shaping and add delay to TCP packets? Unfortunately I'm not familiar with it nor with low level socket programming so I can't provide exact steps.
TagsNo tags attached.
Operating System
PHP Version7.0.20-7.0.24
Attached Files

- Relationships

-  Notes
(0004454)
derick (administrator)
2017-11-06 19:29

Fixed for Xdebug 2.6.

- Issue History
Date Modified Username Field Change
2017-09-12 08:47 matt New Issue
2017-09-20 23:07 derick Status new => acknowledged
2017-09-20 23:07 derick Target Version => 2.7.0dev
2017-10-02 15:04 derick Target Version 2.7.0dev => 2.6.0dev
2017-11-06 19:29 derick Note Added: 0004454
2017-11-06 19:29 derick Status acknowledged => closed
2017-11-06 19:29 derick Assigned To => derick
2017-11-06 19:29 derick Resolution open => fixed
2017-11-06 19:29 derick Fixed in Version => 2.6.0dev
2017-12-02 15:57 derick Fixed in Version 2.6.0dev => 2.6.0alpha1
2017-12-02 18:34 derick Target Version 2.6.0dev => 2.6.0alpha1
2017-12-02 18:36 derick Target Version 2.6.0alpha1 => 2.6.0


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker