Fixed issue #2079: Add pseudo hosts xdebug://gateway and xdebug://nameserver

[derickr]

No description provided.

[derickr]

Hey @rfay, I'm merging this now. It'd be great if you could test to see if xdebug://nameserver and xdebug://gateway would also work for you?

[rfay]

Looking forward to it. I'm not in the habit of building php-xdebug though, so would need to do some work there. Doesn't look like you use releases or provide any built artifacts (which makes sense because of how many places it has to go).

[derickr]

There are build artefacts for Windows on GH Actions for PRs: https://github.com/xdebug/xdebug/actions/runs/2269800395#artifacts — you just need to wait until all 36 checks have run. (soon)

[rfay]

DDEV supports macOS (amd64/arm64/Docker Desktop/colima), Windows (native and WSL2), Linux (all distros),

One of the many things that piques my interest is that DDEV has always had to figure out host.docker.internal for Linux by inspecting the docker bridge... I think you're going to figure that out for me now... ???

This could be a real win for xdebug and people's experience.

[derickr]

I think you're going to figure that out for me now... ???

Yes, you should be able to use xdebug://gateway for that on Linux now.

[rfay]

Sorry, those all look like Windows DLLs to me, I couldn't figure out the name coding. But I did unzip lots and all the ones I did were DLLs. All I need is amd64 and arm64 linux. (All versions of DDEV are running linux containers)

[k0d3r1s]

after this merge, xdebug no longer builds on alpine with error: xdebug.so: res_ninit: symbol not found

[derickr]

On 9 May 2022 22:12:08 BST, "Dāvis Zālītis" ***@***.***> wrote: after this merge, xdebug no longer builds on alpine with error: xdebug.so: res_ninit: symbol not found

Can you please file a bug report at https://bugs.xdebug.org with the full output of ./configure and make? Mostly so that I won't forget, but I'd also like to see the full output.

[rfay]

Tried this on Windows WSL2, but it didn't seem to work and I don't know how to debug it.

 php --version
PHP 7.4.29 (cli) (built: Apr 22 2022 06:45:04) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.29, Copyright (c), by Zend Technologies
    with Xdebug v3.2.0-dev, Copyright (c) 2002-2021, by Derick Rethans

xdebug.client_host => xdebug://gateway => xdebug://gateway

Give me some hints about how to figure out what it's figured out and I'll get farther, thanks!

[derickr]

@rfay:

Xdebug's log (with log level at 10), will show this:

[2100755] [Step Debug] INFO: Found 'gateway' pseudo-host, with IP address '192.168.42.1'.
[2100755] [Step Debug] INFO: Connecting to resolved address/port: 192.168.42.1:9003.
[2100755] [Step Debug] WARN: Creating socket for '192.168.42.1:9003', poll success, but error: Operation now in progress (29).
[2100755] [Step Debug] ERR: Could not connect to debugging client. Tried: 192.168.42.1:9003 (through xdebug.client_host/xdebug.client_port, from xdebug://gateway).

And it will also show in the xdebug_info() output as:

[Step Debug] WARN: Creating socket for '192.168.42.1:9003', poll success, but error: Operation now in progress (29).
[Step Debug] ERR: Could not connect to debugging client. Tried: 192.168.42.1:9003 (through xdebug.client_host/xdebug.client_port, from xdebug://gateway).

If no xdebug log at all is configured, you'll get this in the command line (or Apache log):

Xdebug: [Step Debug] Could not connect to debugging client. Tried: [192.168.42.1:9003](http://192.168.42.1:9003/) (through xdebug.client_host/xdebug.client_port, from xdebug://gateway).

[k0d3r1s]

@derickr https://bugs.xdebug.org/view.php?id=2089

There are no make or configure errors, there are only run errors. Alpine image simply does not have res_ninit function

[rfay]

Here are my results from testing - only Linux actually worked with xdebug.client_host=xdebug://gateway

xdebug gateway testing

Methodology:

DDEV, php7.4.29, with xdebug 3.2.0-dev at bca92fd

xdebug.client_host=xdebug://gateway

• WSL2/Docker Desktop:
  • host.docker.internal (provided by Docker Desktop) is 192.168.5.2 - works
  • resolv.conf in wsl2 provides 192.168.80.1, which also works inside container to access PhpStorm
  • xdebug://gateway tries to use 172.23.0.1, not sure where it comes from, doesn't work
• Windows - host side using Docker Desktop
  • host.docker.internal from docker desktop is 192.168.5.2, works
  • xdebug://gateway tries to use 172.23.0.1, doesn't work
• macOS (arm64), Docker Desktop
  • host.docker.internal is 192.168.5.2 - works
  • xdebug://gateway tries 172.24.0.1 - doesn't work
• Ubuntu 20.04 with docker-ce
  • host.docker.internal derived by ddev from docker network inspect bridge is 72.17.0.1 (works)
  • xdebug://gateway tries 172.19.0.1 (works)

[derickr]

Hi @rfay,

thanks for testing this. You've picked different categories (or names) then my set-ups from https://docs.google.com/document/d/1W-NzNtExf5C4eOu3rRQm1WlWnbW44u3ANDDA49d3FD4/edit?usp=sharing, so I am a little confused. It'd be great if you could conflate the headings/set-up names. You also don't mention where the IDE runs at, which might skew things.

1. I don't quite understand what the difference is between WSL2/Docker Desktop and Windows - host side using Docker Desktop, can you clarify that?
2. In WSL2/Docker Desktop (my PHP/Xdebug Running in Docker for Windows (Docker Desktop) in WSL, (Linux version of) IDE in WSL, I think), can you try the xdebug://nameserver pseudo-host instead? That should read it from /etc/resolv.conf, unless Alpine Linux is involved, which has a broken resolver implementation.
3. Can you, for each of these four cases do a sudo route -n and cat /etc/resolv.conf inside the docker container (where also PHP and Xdebug run)?

I think that with Docker Desktop, they do something odd networking wise and I need to find out how to see the host.docker.internal IP without using that, if possible.

cheers,
Derick