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.

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.e., username and password) would also prevent interoperability with current IDE implementations.

They also stipulated that I didn't need an assigned port due to the fact that most of the traffic runs on LANs only, and that there are other ways of negotiating a suitable port. All in all, neither requirement makes the use of Xdebug and DBGp easier.

Interestingly enough, they did write that it was "inappropriate" to use any currently assigned port—TCP/9000 is also used for cslistener. However, if they don't want to assign DBGp a port, than what am I supposed to do?

There is still one bug that I want to address for the first release candidate, and that is a long outstanding bug where Xdebug accesses variables passed into a function after PHP has already freed this information. I have created haphazard solutions in the past, but they never fully addressed the problem. They are hard to reproduce cases, and therefore I was happy to see a submitted pull request with test cases, and even a patch. The idea behind the patch is good, but only for one case, where the arguments are an object. The problem isn't only related to objects, and henceforth needs a more general solution. Nikita was happy to provide a suggested fix, which I will now have to put into practice.

At the end of the month I started a thread on Twitter (now deleted) with the cheeky suggestion that I am considering making Xdebug non-free for commercial use. This is not something I would likely do, and instead would prefer to be funded through Patreon and commercial donations. The replies on the thread gave me a couple of ideas to make this more likely to work.

For companies it can often be complicated to use things like Patreon, as it's difficult for accounting or "selling it to management". I am therefore going to make it possible for companies to "buy a license", with a yearly invoice.

Another suggestion was to set up funding goals, which indicate how much time I can dedicate to working on Xdebug, with various levels of improvements. I have now done so on Patreon, with the following goals:

• Maintain: I can dedicate enough time to Xdebug to continue supporting it in its current form, and making sure there is a new Xdebug version to complement new PHP versions. This might not necessarily include fixing all the more complicated bugs (Currently at 69%).

• Feature: Not only will I have enough time to maintain Xdebug with newer PHP versions, but I will also be able to work on some requested features, and dive deeper into more complicated bugs (Currently at 34%).

• Re-architect and performance: Besides maintenance and new features, I can now dedicate time to rewrite the parts of Xdebug that particularly slow, and re-architect it to be more much maintainable. The main reason for wanting to do that is performance, performance, and performance (Currently at 17%).

I will likely add these goals to the website as well, where I can also include company contributions. Let's see if we can get all of them to 100% together!

In order to make it easier to convince people to sign up, I am planning on making live coding sessions available to Patreon backers (of some higher levels), as well as providing commercial support for setting up Xdebug. These plans need a little bit more thought, so expect to hear from me about these in the near future.

I have been continuing with the PHP Internals News podcast. In this weekly podcast, I discuss in 15-30 minutes, proposed new features to the PHP language with fellow PHP internals developers. It is available on Spotify and iTunes, and through an RSS Feed. Let me know if you are a listener!