I want to use VSCode’s ‘PHP Debug’ plugin with Xdebug to debug PHP scripts.
But when I choose “Debug|Start Debugging F5” the little debug pop-up appears and I am stuck. Buttons for Pause, Restart, Stop are active. Buttons for Step over, into, out are inactive (greyed out). Nothing happens in the debug console.
(1) VSCode 1.42.1 is installed
(2) XAMPP v3.2.4 is up and running
(3) Xdebug is installed using the wizzard and pasting my phpinfo() data to determine the correct version. When I start ‘admin’ from XAMPP Control Panel and review phpinfo, the browser shows me (amongst many other things):
[...]
This program makes use of the Zend Scripting Language Engine:
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Xdebug v2.9.2, Copyright (c) 2002-2020, by Derick Rethans
[...]
(4) php.ini
has
[XDEBUG]
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.show_local_vars = 1
xdebug.remote_log = "C:Program Files_xamppphplogsxdebug.log"
zend_extension = "php_xdebug-2.9.2-7.4-vc15-x86_64.dll"
(please note that “Program Files_” is NOT the protected “Program Files” directory, XAMPP has write access as shown for point (9) below)
(5) the Windows path has C:Program Files_xamppphp;
in it
(6) when I use Code Runner extension in VSCode to run a “Hello World.php” script is runs just fine
(7) launch.json
for the VSCode debugger has
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000,
}
]
(8) my Windows firewall has an inbound rule to allow TCP traffic on port 9000.
(9) when I just run the code, xdebug.log (see php.ini
) is updated with
[94396] Log opened at 2020-03-08 07:45:28
[94396] I: Connecting to configured address/port: localhost:9000.
[94396] E: Time-out connecting to client (Waited: 200 ms). :-(
[94396] Log closed at 2020-03-08 07:45:28
But when I use “Debug|Start Debugging F5” nothing happens in xdebug.log.
That is all the information that I thought relevant so far. Which leaves me like so:
me -> update_status("at wit's end")
Do you wizards out there have any idea where to dig? Which config file to tweak? Which log file to consult?
footnote: debugging of Python scripts in VSCode works just as expected.
3
Answers
@LazyOne's comment provided the clue and the tools to stumble upon the solution ...
And the answer turns out to be quite embarrassing.
Long story (how to check that VSCode is listening on port 9000)
telnet 0.0.0.0 9000
ortelnet localhost 9000
in the shell and observe the connection failtelnet 0.0.0.0 9000
ortelnet localhost 9000
in the shell and note the difference: you are connected to VScode!Conclude that VSCode is indeed listening to both 0.0.0.0:9000 and localhost:9000.
launch.json
had 2 configurationslaunch.json
is used to debug a script that was started from a browser session: (i) set your breakpoints in VSCode, (ii) start debugging with "Listen for XDebug" configuration, (iii) start the scripts by initiating a request i the browser, (iv) observe VSCode if a breakpoint is triggered while the request is processedShort Story
Make sure that "Launch currently open script" is selected as configuration when you start debugging your php script in VSCode, see screenshot below.
Afterthought
I have changed my
launch.json
toThis way the "Launch currently open script" is the default and will be used when I start debugging with "Debug|Start Debugging F5" from the main menu.
launch.json (default config):
In php.ini is absolutely essential to include the directive xdebug.idkey=VSCODE, even though I haven’t found any reference to it in the documentation.
I just ran into this issue, where I was trying to listen to XDebug and nothing happened when I tried to hit F5 or Run/Debug…
It turns out some phantom folder had been added to my workspace (I had been running a bunch of test with some upgrade tool for the application I’m working on, so I guess that’s where that came from?).
Removing that "extra" folder from the workspace was all I needed to do to be able to "run" the debug process again. Hopefully this can help someone else (not feel so dumb as I did) with a similar issue.