3

I've encountered a weird problem that seems to have either started appearing when the Xdebug extension was updated or Visual Studio Code received an update.

When the debugger is active in VSCode the website works fine, when stopping the debugger, the Xdebug extension within the docker container seems to be unable to disconnect. And the website is stuck in a loading state.

I receive the following message in the xdebug.log when trying to access the site when the debugger is stopped in VSCode.

[318] Log opened at 2022-04-08 12:19:15.819009
[318] [Step Debug] INFO: Connecting to configured address/port: host.docker.internal:9001.
[318] [Step Debug] INFO: Connected to debugging client: host.docker.internal:9001 (through xdebug.client_host/xdebug.client_port). :-)
[318] [Step Debug] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/html/index.php" language="PHP" xdebug:language_version="7.4.0" protocol_version="1.0" appid="318" idekey="VSCODE"><engine version="3.1.4"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2022 by Derick Rethans]]></copyright></init>

This seems like the Xdebug extension still tries to connect (successfully) to the listening port at 9001.

But the port is not listening on the host, when checking with lsof -i :9001.

PHP Xdebug settings:

zend_extension=xdebug.so
xdebug.mode=debug
xdebug.remote_handler=dbgp
xdebug.idekey=VSCODE
xdebug.start_with_request=yes
xdebug.log=/tmp/xdebug.log
xdebug.client_host=host.docker.internal
xdebug.client_port=9001
xdebug.discover_client_host=0

launch.json settings:

{
    "version": "0.2.0",
    "configurations": [{
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9001,
            "log": false,
            "externalConsole": false,
            "pathMappings": {
                "/var/www/html": "${workspaceFolder}",
            },
            "ignore": [
                "shared/vendor/*"
            ]
        },
    ]
}

I've also tried with a different client_host setting. Added an alias to the en0 interface, to reach the host IP from Xdebug.

sudo ifconfig en0 alias 10.128.128.128 255.255.255.0

No variation of settings seems to eliminate this problem, anyone has any ideas?

LazyOne
  • 158,824
  • 45
  • 388
  • 391
JazzCat
  • 4,243
  • 1
  • 26
  • 40
  • 1) `xdebug.start_with_request=yes` -- if you remove this line then Xdebug will stop trying to debug every single script. 2) Although, this does not explain why it keeps running when it gets no further response. 3) Not a Mac user here, but will `sudo lsof -nP -iTCP -sTCP:LISTEN` kind of line show any different result for `9001` port? Something must still be listening there.... 4) Will it behave differently if you use default for Xdebug 3 `9003` port? 5) Will it behave any differently after rebooting your Mac? The reboot can solve different things, it's not Windows-only magic :) – LazyOne Apr 08 '22 at 18:16
  • P.S. `xdebug.remote_handler=dbgp` -- that's Xdebug v2 option and it is _deprecated_ even there. – LazyOne Apr 08 '22 at 18:17
  • 1. Without xdebug.start_with_request it doesnt catch the breakpoints. 3. It lists all listening ports, 9001 is not included there 4. Nope, same issue 5. Works until you start debugging and then stop the debugger, then you get stuck in the same loading state. The dbgp setting did no good, thanks, removed that. – JazzCat Apr 08 '22 at 19:36
  • Well ... the fact that Xdebug gets connected suggests that there is some service somewhere that still listen on Xdebug port. No idea on what that might be. *"Without xdebug.start_with_request it doesnt catch the breakpoints."* Not 100% correct. It can work without that line just fine. But that depends on the stack used/subrequests involved etc. What are you debugging -- a web page or a CLI script? For a web page -- have you tried Xdebug browser extension? It sets Xdebug cookie that works as a "debug me" flag (also can be a GET/POST parameter). https://xdebug.org/docs/step_debug#web-application – LazyOne Apr 08 '22 at 20:09
  • Its a PHP framework, no havent tried the browser extension, good idea, Ill look into that – JazzCat Apr 09 '22 at 21:13
  • Still no luck, thing is that this has worked with the same configuration until last month and something broke it. – JazzCat Apr 10 '22 at 11:41
  • 2
    This seems to be related: https://stackoverflow.com/questions/71624622/closed-ports-on-docker-host-osx-are-staying-reporting-open-on-the-internal-doc – JazzCat Apr 10 '22 at 11:49
  • 1
    Docker ticket: https://github.com/docker/for-mac/issues/6247 – LazyOne Apr 20 '22 at 15:53

1 Answers1

0

The 4.8.0 build solves this issue.

The Docker for mac ticket: https://github.com/docker/for-mac/issues/6235

The builds that resolves the issue:

Intel: https://desktop-stage.docker.com/mac/main/amd64/78146/Docker.dmg

Apple silicon: https://desktop-stage.docker.com/mac/main/arm64/78146/Docker.dmg

JazzCat
  • 4,243
  • 1
  • 26
  • 40