4

In Visual Studio Code (1.9.1) (mac) i have setup the php-debug plugin.

In the debug screen i start 'listen for Xdebug'.
After this i open the index.php on my XAMPP server (local).
But nothing happens.

  • the blue bar at the bottom of the screen turns orange.
  • the step over, step into and step out buttons are greyed out.
  • Also the following error message occurs at the watched variables:
    cannot evaluate code without an connection

I try to use breakpoints on the following code:

<?php
$i = 0;

do {
$i++;
if (!($i % 1)) {
    echo('<p>$i = ' . $i . '</p>');
    }
}
while ($i < 100);
?>

I am using XAMPP and in my php.ini file i use port 9000 for Xdebug.

zend_extension="/usr/local/Cellar/php71-xdebug/2.5.0/xdebug.so"
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote.port=9000

I installed Xdebug using homebrew.
Here is my php info: phpinfo.htm
Xdebug wizard tells me Xdebug is installed correctly.

my launch.json file looks like this:

{
"version": "0.2.0",
"configurations": [
    {
        "name": "Listen for XDebug",
        "type": "php",
        "request": "launch",
        "port": 9000,
        "log": true
    },
    {
        "name": "Launch currently open script",
        "type": "php",
        "request": "launch",
        "program": "${file}",
        "cwd": "${fileDirname}",
        "port": 9000
    }
]
}

Would anyone know what i am doing wrong?

After setting the xdebug.remote_connect_back = 1 in the ini file
as n00dl3 suggested debugging most of the time works, but once in a while i get the following
error in the debug console:

<- threadEvent
ThreadEvent {
  seq: 0,
  type: 'event',
  event: 'thread',
  body: { reason: 'exited', threadId: 1 } }
Trapce
  • 63
  • 1
  • 1
  • 9
  • did you try to set `xdebug.remote_connect_back = 1` in your ini file ? – n00dl3 Feb 21 '17 at 13:26
  • It seems to work most of the time now, but once in a while i get the following error in the debug console: ` <- threadEvent ThreadEvent { seq: 0, type: 'event', event: 'thread', body: { reason: 'exited', threadId: 1 } }` – Trapce Feb 21 '17 at 14:10
  • No idea about that – n00dl3 Feb 21 '17 at 14:15
  • [seems related](https://github.com/Microsoft/vscode/issues/1703) – n00dl3 Feb 21 '17 at 14:18

6 Answers6

6

I encountered this problem as well, not with the same environment (NGINX server + php-fpm) but the same symptoms. It turned out to be caused by my xdebug configuration.

How I managed to diagnose it : by writing a simple PHP script for test just like OP did :

<?php

xdebug_info();

By browsing to it, I got a bunch of info on my setup, including :

xdebug.client_host => localhost
xdebug.client_port => 9003

whereas my xdebug was listening on port 9900 (default being 9000).

Steps to fix : just add the following lines to your php.ini or xdebug.ini (wherever the rest of your xdebug configuration lies) :

# This should match your xdebug.remote_host
xdebug.client_host=localhost
# This should match your xdebug.remote_port
xdebug.client_port=9900
xdebug.mode=debug

Then rerun a debug session in VScode, add some breakpoints, and re-browse to your script : my VScode window popped up, the execution was paused on the breakpoint and the variables where accessible in the debug pannel just like expected.

EDIT : don't forget to also :

  • add xdebug.mode=debug to your php.ini
  • restart webserver and php-fpm services.
theolem
  • 71
  • 1
  • 4
2

It seemed the server root needed to be set in the launch.json with localSourceRoot like this:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "log": true,
            "localSourceRoot": "http://127.0.0.1/public_html/"
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
        }
    ]
}

Now breakpoints are working like they should.

Gnimuc
  • 8,098
  • 2
  • 36
  • 50
Trapce
  • 63
  • 1
  • 1
  • 9
1

In my case, these two lines were missing from the php.ini file.

 xdebug.mode = debug
 xdebug.start_with_request = yes
zainul ogna
  • 160
  • 2
  • 4
0

Check xdebug.client_port in page xdebug_info(); or phpinfo();

Config same port in launch.json of vscode

Rithy
  • 184
  • 2
  • 3
  • 14
0

I just had this problem too.

Somehow, someday, without realizing it, I got version 3 of xdebug installed, and a lot of conf param name changed , see this SO question

So verifying the xdebug version with phpinfo for example can be worth a shot.

0

I am working with VSCODE devcontainer and I fix with the config below:

My launch.json for VSCODE

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Xdebug",
            "type": "php",
            "request": "launch",
            "port": 9003
        }
    ]
}

I use Dockerfile with a RUN below to install xdebug:

RUN pecl install xdebug && docker-php-ext-enable xdebug

I find my xdebug config file in /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

I edit the file as below:

zend_extension=xdebug

[xdebug]
xdebug.mode=debug
xdebug.client_host=host.docker.internal
xdebug.start_with_request=yes
xdebug.idekey=VSCODE

Or you can add it in Dockfile like below:

RUN echo ' \n[xdebug] \n\
xdebug.client_host=host.docker.internal  \n\
xdebug.mode=debug  \n\
xdebug.start_with_request=yes \n\
xdebug.idekey="VSCODE"  \n\
\n' >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

mode This setting controls which Xdebug features are enabled. We’ve set develop to enable development aids, such as getting better error messages, and debug to enable step debugging.

client_host This setting tells Xdebug the IP address or hostname of the machine that is running your text editor or IDE.

start_with_request This setting determines whether a function trace, garbage collection statistics, profiling, or step debugging are activated at the start of a PHP request. Setting it to yes instructs Xdebug to always initiate a debugging session.

ikhvjs
  • 5,316
  • 2
  • 13
  • 36