Xdebug Update: August 2019

London, UK

Tuesday, September 10th 2019, 09:25 BST

This is another of the monthly update reports in which I explain what happened with Xdebug development in this past month. It will be published on the first Tuesday after the 5th of each month. Patreon supporters will get it earlier, on the first of each month. You can become a patron here to support my work on Xdebug. More supporters, means that I can dedicate more of my time to improving Xdebug.

In August, I worked on the following things:

2.8.0beta2 Release

This second beta release addresses a lot of issues that were still outstanding for the 2.8 release. This included simple issues like Wrong name displayed for Recoverable fatal errors and Code Coverage misses fluent interface function call. The trickiest bug was related to the DBGp debugging protocol.

I test Xdebug's implementation of the DBGp protocol by having a file with the PHP script to debug and then a phpt test that has a set of commands to run against that file. As an example, for one of the fixed bugs, the script looks like:

<?php function breakpoint1()
{
        echo base64_encode("testing"), "\n";
        strlen();
}

breakpoint1();
??>

And the phpt test looks like:

<?php require 'dbgp/dbgpclient.php';
$filename = realpath( dirname(__FILE__) . '/bug01388-01.inc' );

$commands = array(
        'feature_get -n resolved_breakpoints',
        "breakpoint_set -t line -f file://{$filename} -n 4",
        'breakpoint_list',
        'feature_set -n resolved_breakpoints -v 1',
        'feature_get -n resolved_breakpoints',
        'breakpoint_list',
        "breakpoint_set -t line -f file://{$filename} -n 4",
        'breakpoint_list',
        'detach',
);

dbgpRunFile( $filename, $commands );
??>

The third command sets a breakpoint on line 4 (the echo statement) and then does various things related to breakpoint resolving. The "remote log" that is generated by the test is then compared (after some regexp replacements) with the expected output.

Because I run the script in a new process, I have some methods in place to also collect the output of the script (both stdout and stderr). I don't usually have stderr on, as there are a few false positives, but when I tested with this in the past, I noticed that one test caused a segmentation fault.

After a few hours of trying to find out the problem, I noticed that this would only happen in the init state (when the debugger first connects to the IDE, and when the IDE can enable features and send breakpoints). If in this init state the IDE would send the detach command, Xdebug would crash. This detach command can be used by an IDE to disengage the debugger, with the script continuing to run afterwards.

Due to an implementation bug related to whether the debugger connection was active or not, a detach in the init state would mark the connection active, while the connection was already cleaned up before hand. This caused Xdebug to access memory, that was already freed (which is a bad thing to do). The fix was luckily quite simple.

IANA Port Assignment

As a result of a twitter conversation that I had, I tried applying for an "assigned port" for the DBGp protocol. As some of you might be aware, Xdebug shares the same default port (9000) as PHP-FPM. This has caused confusion in the past, so I was hoping to avoid future problems with Xdebug 3 by asking IANA to assign me one. However, IANA declined by application by somewhat vague comments about "security" and not needing one because DBGp runs on a LAN.

As to the security aspect, they require authentication and encryption for new protocols, and of course DBGp isn't new. I would like to add an encryption layer to DBGp, but I can't require this right away, as that would mean no IDE can talk DBGp any more. Requiring authentication (i.