Xdebug Update: August 2023

In this monthly update I explain what happened with Xdebug development in the past month. These are normally published on the first Tuesday on or after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 36% towards my $2,500 per month goal, which is set to allow continued maintenance of Xdebug.

If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In the last month, I spend around 27 hours on Xdebug, with 32 hours funded.

<?php
class Handlers
{
    function __construct(private string $title, private float $PIE) {}

    static function exceptionHandler($exception)
    {
        $s = xdebug_get_function_stack( [ 'from_exception' => $exception ] );
        var_dump($s);
    }
}

class Error_Entry
{
    public function __construct($base, $errno)
    {
        throw new Exception();
    }
}

set_exception_handler(['Handlers', 'exceptionHandler']);
$e = new Error_Entry(1, 2);

?>

Xdebug Update: July 2023

In this monthly update I explain what happened with Xdebug development in this past two months. These are normally published on the first Tuesday on or after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 37% towards my $2,500 per month goal, which is set to allow continued maintenance of Xdebug.

If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In the last month, I spend around 15 hours on Xdebug, with 25 hours funded. This is much less than I wanted, but instead I have been busy implementing features for PHP.

Xdebug Cloud

Xdebug Cloud is the Proxy As A Service platform to allow for debugging in more scenarios, where it is hard, or impossible, to have Xdebug make a connection to the IDE. It is continuing to operate as Beta release.

Packages start at £49/month, and I have recently introduced a package for larger companies. This has a larger initial set of tokens, and discounted extra tokens.

If you want to be kept up to date with Xdebug Cloud, please sign up to the mailinglist, which I will use to send out an update not more than once a month.

Concealed Code

Last week, the author of the PHP Debug Adapter for Visual Studio Code asked me to look at an issue. A user noticed that configured breakpoints in the editor would be greyed out for any request besides the first one for each process when using PHP's built-in web server.

Xdebug "resolves" breakpoints when it sees code compiled by PHP and then notifies IDEs that the configured breakpoints are valid. Sometimes it also means it moves them to a line with executable code on it, as in some cases, PHP is "confused" about where lines of code live.

I spent some time delving into this, and initially I could not reproduce this. On my side (Linux, PHP 8.1/8.2) with php -S the behaviour was always correct, with the breakpoints resolved for each request through the dev server.

When I had another good look at the phpinfo() output from the user, I noticed:

Zend Engine v4.2.8, Copyright (c) Zend Technologies
        with Xdebug v3.2.2, Copyright (c) 2002-2023, by Derick Rethans
        with Zend OPcache v8.2.8, Copyright (c), by Zend Technologies

The above shows that Xdebug is loaded first and OPcache second, which the documentation says you shouldn't do:

Zend Opcache

Can be loaded together with Xdebug, but it is not 100% compatible.

Load Xdebug after Opcache in php.ini for better compatibility. When running php -v or when looking at phpinfo() output, Xdebug should be listed below Opcache.

After I switched the loading order of the two Zend extensions, loaded on the command line after ignoring (through -n) the normal php.ini file from:

XDEBUG_MODE=debug XDEBUG_TRIGGER=yes \
        php -n -d zend_extension=opcache -d zend_extension=xdebug \
        -S localhost:9112 -t /tmp

To:

XDEBUG_MODE=debug XDEBUG_TRIGGER=yes \
        php -n -d zend_extension=xdebug -d zend_extension=opcache \
        -S localhost:9112 -t /tmp

I could reproduce this issue.

The explanation for this is that both Xdebug and OPcache override PHP's compile file handler.

Xdebug uses this to analyse newly loaded files for lines of code that can have breakpoints to resolve them. Before doing its magic, it calls the already present handler, nominally, the built-in PHP one that converts a PHP script into byte code that the PHP engine can run.

OPcache uses the handler to see whether it sees a file being converted (parsed) for a second time. If it is in its cache, it doesn't call PHP's original compile handler again but instead returns the byte code from its cache.

If OPcache is loaded first and then Xdebug, the following sequence occurs:

• OPcache replaces the compile file handler with opcache_compile_file, and remembers the previous one, php_compile_file.

• Xdebug replaces the compile file handler with xdebug_compile_file, and remembers the previous one, now opcache_compile_file.

In this situation, when PHP runs the compile file handler, it first calls xdebug_compile_file, which then calls opcache_compile_file and all is well.

The process reverses if OPcache is loaded last:

• Xdebug replaces the compile file handler with xdebug_compile_file, and remembers the previous one, php_compile_file.

• OPcache replaces the compile file handler with opcache_compile_file, and remembers the previous one, now xdebug_compile_file.

When PHP runs the compile file handler, it calls opcache_compile first. OPcache checks whether it has seen the file already and, if not, calls the previous handler (xdebug_compile_file), but if it has seen the file already (the second request through a php -S server), it does not call the previous compile file handler.

Typically, that is what you want, as compiling files is expensive. However, because it does not call th