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 April, I worked on the following things:
The 2.7.1 release came just at the start of the month, and addressed three bugs:
Issue #1646: Missing newline in error message.
Issue #1647: Memory corruption when a conditional breakpoint is used.
The second bug in the list was more than just a missing newline. Xdebug's handling of connections that were aborted by the IDE was not as good as they could be. For this to be tested, I updated the test harness for remote debugger tests to be able to test for
stderr as well.
I would recommend that everybody to update to this version as the last of these bugs can cause PHP with Xdebug to crash.
Since the Xdebug 2.7.1 release I have worked on a few outstanding bugs that did not make the earlier 2.7 releases.
The remote step debugger allows you to change a variable's value through an IDE. Previously, this would use PHP's internal
eval functionality to set the value, except in the cases where the IDE would also associate a new type with the value. I finally switched all code paths of setting new values to use
eval. Due to changes introduced in PHP 7, this is now the only reliable way of doing this.
The second issue (#1656) fixes an issue with the step debugger's connect-back functionality. This functionality looks at HTTP headers to find out which IP address to connect to. In some cases, a proxy might inject a second IP address, and Xdebug could not handle this. I improved upon a prototype patch by Florian Dorn to make Xdebug now pick the first IP address in the header that it finds.
Through the implementation of issue (#1615), Xdebug now will turn off Zend OPcache's optimiser when the step debugger is active. The optimiser is really good making crappy code run fast, but it also optimises things away that normal users wouldn't expect, and that then confuses developers single-stepping through their code. Which brings me onto the last point of this update:
In last month's update I introduced a new feature that Jetbrains is sponsoring. This issue, #1388: Support 'resolved' flag for breakpoints, is now implemented pending additional testing with a fresh (and experimental) build of PhpStorm. As part of the testing I'm interested in knowing how many breakpoints are usually in use in PhpStorm projects. I would be interested in knowing how many breakpoints, and which types of breakpoints (location, exception), your project has defined. Please leave a note in the comment section if you care to help me out with this.
I have also been continuing with the PHP Internals News podcast. This is a weekly podcast where in 15-30 minutes I discuss new proposed 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!