The 2.7.1 release came just at the start of the month, and addressed three bugs:

• Issue #1641: Performance degradation with getpid syscall, contributed by Kees Hoekzema.

• 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 stdout and 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!