Planet PHP
Guest
Xdebug Update: May 2019
London, UK
Tuesday, June 11th 2019, 09:17 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 May, I worked on Xdebug for 32 hours, and did the following things:
2.7.2 Release
I made the 2.7.2 release release available at the start of the month. This released addressed a few bugs:
The first issue has been lingering since when Xdebug introduced support for PHP 7. PHP 7 changes the way how variables are handled in the engine, which means that is a lot harder to obtain a zval structure that is modifiable. Xdebug uses that existing functionality in the step debugger to modify a variable's contents, but only if a variable type was explicitly set as well. Because it is no longer possible to retrieve this zval structure for modification, Xdebug switched from direct modification to calling the engine's internal eval_string function to set new values for variables.
Xdebug's wrapper around the engine's eval_string function is also used when running the DBGp eval command. IDEs use this for implementing watch statements. Because Xdebug shouldn't leak warning or error messages during the use of DBGp protocol commands, Xdebug's wrapper sets error_reporting to 0. However, that means if you would run error_reporting() through the DBGp protocol with the eval command, it would always return 0. The second bug (#1586) fixed this, so that running error_reporting() with eval now returns the correct value.
The third issue in the list addresses a problem with Zend OPcache's optimiser turned on. It is possible that with optimisations turned on, variables no longer exist, or useless statements are removed to make your code run faster. However, this is highly annoying when you are debugging, because you can no longer reliably inspect what is going on. By turning of the code optimisation when Xdebug's step debugger is active, normality is restored.
The last two items in the 2.7.2 release are minor bug fixes.
Resolving Breakpoints
The fine folks at Jetbrains have looked at my implementation of issue #1388: Support 'resolved' flag for breakpoints. They found that although the implemented functionality works, it would not yet handle the resolving of breakpoints which are set in a scope that is currently being executed (i.e., when the function, method, or closure is currently active). I have briefly looked at solving this problem, but have not yet found a good solution. In addition, I am intending to change the line searching algorithm to scan at most 5 lines in each directions instead of 10. This should prevent unnecessary jumping around, and unintended breaks.
PHP 7.4 Support
The rest of th
Truncated by Planet PHP, read more at the original (another 1793 bytes)
Читать дальше...
London, UK
Tuesday, June 11th 2019, 09:17 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 May, I worked on Xdebug for 32 hours, and did the following things:
2.7.2 Release
I made the 2.7.2 release release available at the start of the month. This released addressed a few bugs:
Issue #1488: Rewrite DBGp 'property_set' to always use eval
Issue #1586: error_reporting()'s return value is incorrect during debugger's 'eval' command
Issue #1615: Turn off Zend OPcache when remote debugger is turned on
Issue #1656: remote_connect_back alters header if multiple values are present
Issue #1662: __debugInfo should not be used for user-defined classes
The first issue has been lingering since when Xdebug introduced support for PHP 7. PHP 7 changes the way how variables are handled in the engine, which means that is a lot harder to obtain a zval structure that is modifiable. Xdebug uses that existing functionality in the step debugger to modify a variable's contents, but only if a variable type was explicitly set as well. Because it is no longer possible to retrieve this zval structure for modification, Xdebug switched from direct modification to calling the engine's internal eval_string function to set new values for variables.
Xdebug's wrapper around the engine's eval_string function is also used when running the DBGp eval command. IDEs use this for implementing watch statements. Because Xdebug shouldn't leak warning or error messages during the use of DBGp protocol commands, Xdebug's wrapper sets error_reporting to 0. However, that means if you would run error_reporting() through the DBGp protocol with the eval command, it would always return 0. The second bug (#1586) fixed this, so that running error_reporting() with eval now returns the correct value.
The third issue in the list addresses a problem with Zend OPcache's optimiser turned on. It is possible that with optimisations turned on, variables no longer exist, or useless statements are removed to make your code run faster. However, this is highly annoying when you are debugging, because you can no longer reliably inspect what is going on. By turning of the code optimisation when Xdebug's step debugger is active, normality is restored.
The last two items in the 2.7.2 release are minor bug fixes.
Resolving Breakpoints
The fine folks at Jetbrains have looked at my implementation of issue #1388: Support 'resolved' flag for breakpoints. They found that although the implemented functionality works, it would not yet handle the resolving of breakpoints which are set in a scope that is currently being executed (i.e., when the function, method, or closure is currently active). I have briefly looked at solving this problem, but have not yet found a good solution. In addition, I am intending to change the line searching algorithm to scan at most 5 lines in each directions instead of 10. This should prevent unnecessary jumping around, and unintended breaks.
PHP 7.4 Support
The rest of th
Truncated by Planet PHP, read more at the original (another 1793 bytes)
Читать дальше...