Unable to debug using Vagrant with custom PHP 7.2 installed and VSCode using Firefox, VSCode fails to break into a breakpoint

Question

In my project I have the following Xdebug settings on a Vagrant running VM:

zend_extension=xdebug.so
xdebug.remote_host=10.0.2.2
debug.repomote_port=9000
xdebug.remote_enable=1
xdebug.max_nesting_level = 1000
xdebug.remote_log=/tmp/xdebug.log

Whilst on VSCode I have set it up like that:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "pathMappings": {
                "/home/vagrant/code": "${workspaceRoot}",
            }
        }
    ]
}

The xdebug settings are located into inside a vagrant vm whilst the ide is on the host. The host Ip ( 10.0.2.2 ) is provided via the command: netstat -rn | grep "^0.0.0.0 " | cut -d " " -f10 netstat -rn | grep "^0.0.0.0 " | cut -d " " -f10

Then I enable the debugging on the Firefox using the xdebug-helper with the following settings:

But my IDE it fails to stop the execution on a breakpoint. Whilst debugging it I opened a shell session with the Vagrant running VM:

vagrant up && vagrant ssh

And then I test the reverse connection with it into the port 9000 using TCP protocol using the command (after having enabled the VSCode into listening for xdebug):

nc -z -v 10.0.2.2 9000

The command itself shows the message:

Connection to 10.0.2.2 9000 port [tcp/*] succeeded!

Also my nginx.conf says:

server {
    listen 80;

    server_name example.com;

    root /home/vagrant/code;

    index index.php index.html;

    charset utf-8;  

    keepalive_timeout 65;
    server_tokens off; 

    sendfile off;

    access_log off;
    error_log  /var/log/nginx/error.log;

    proxy_buffer_size   128k;
    proxy_buffers   4 256k;
    proxy_busy_buffers_size   256k;


    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;

        fastcgi_pass unix:/run/php/php7.1-fpm.sock;
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;
    }

    location ~* ^.+\.(?:css|cur|js|jpe?g|gif|htc|ico|png|html|xml|otf|ttf|eot|woff|svg)$ {
        access_log off;
        expires 30d;
        tcp_nodelay off;

        ## Set the OS file cache.
        open_file_cache max=3000 inactive=120s;
        open_file_cache_valid 45s;
        open_file_cache_min_uses 2;
        open_file_cache_errors off;
    }

    location ~ /\.ht {
        deny all;
    }
}

And the Vagrantfile is the following:

Vagrant.configure("2") do |config|

    config.vm.box = "ubuntu/xenial64"
    config.vm.box_version = "20180917.0.0"
    config.vm.box_download_insecure = true

    config.vm.provider "virtualbox" do |vb|
        vb.name = "example-website"

        vb.memory = 3072
        vb.cpus = 2

        vb.customize [ "modifyvm", :id, "--uartmode1", "disconnected" ]
    end

    config.vm.network "private_network", ip: "192.168.10.80"
    config.vm.network "forwarded_port", guest: 80, host: 8090
    config.vm.network "forwarded_port", guest: 22, host: 2922

    config.vm.synced_folder "./.", "/home/vagrant/code"

    config.vm.provision :shell, :path => "./machine/provision/provision-xenial64.sh"
    config.vm.provision :shell, :path => "./machine/provision/provision-hosts.sh"
    config.vm.provision :shell, :path => "./machine/provision/provision-docker.sh"
    config.vm.provision :shell, :path => "./machine/provision/provision-nginx.sh"
    config.vm.provision :shell, :path => "./machine/provision/provision-php.sh"

    config.vm.provision :docker_compose, yml: "/home/vagrant/code/machine/docker_compose/cue.yml", run: "always"
end

Also the VSCode instance is a vscodium build as well and has the felixfbecker.php-debug plugin. Do you know why the VSCodium fails to break into a breakpoint?

Answer 1

Does the code actually being called?

Sometimes because of a frontend bug especially on ajax calling events your code it may not even called at all. So ensure first that your code is actually called and then try to figure out whether it is an xdebug issue.

So as seen the connection on xdebug from guest into host is being performed. And the ip is set correctly. So it is rather plausible for the piece of code that has the breakpoint not to be called at all, so the IDE does not break into the expected breakpoint.