Concealed Code
London, UK
Thursday, August 3rd 2023, 09:55 BST
Last week, the author of the PHP Debug Adapter for Visual Studio Code asked me to look at an issue. A user noticed that configured breakpoints in the editor would be greyed out for any request besides the first one
for each process when using PHP's built-in web server.
Xdebug "resolves" breakpoints when it sees code compiled by PHP and then notifies IDEs that the configured breakpoints are valid. Sometimes it also means it moves them to a line with executable code on it, as in some cases, PHP is "confused" about where lines of code live.
I spent some time delving into this, and initially I could not reproduce this. On my side (Linux, PHP 8.1/8.2) with php -S
the behaviour was always correct, with the breakpoints resolved for each request through the dev server.
When I had another good look at the phpinfo()
output from the user, I noticed:
Zend Engine v4.2.8, Copyright (c) Zend Technologies
with Xdebug v3.2.2, Copyright (c) 2002-2023, by Derick Rethans
with Zend OPcache v8.2.8, Copyright (c), by Zend Technologies
The above shows that Xdebug is loaded first and OPcache second, which the documentation says you shouldn't do:
Zend Opcache
Can be loaded together with Xdebug, but it is not 100% compatible.
Load Xdebug after Opcache in php.ini
for better compatibility. When running php -v
or when looking at phpinfo()
output, Xdebug should be listed below Opcache.
After I switched the loading order of the two Zend extensions, loaded on the command line after ignoring (through -n
) the normal php.ini
file from:
XDEBUG_MODE=debug XDEBUG_TRIGGER=yes \
php -n -d zend_extension=opcache -d zend_extension=xdebug \
-S localhost:9112 -t /tmp
To:
XDEBUG_MODE=debug XDEBUG_TRIGGER=yes \
php -n -d zend_extension=xdebug -d zend_extension=opcache \
-S localhost:9112 -t /tmp
I could reproduce this issue.
The explanation for this is that both Xdebug and OPcache override PHP's compile file handler.
Xdebug uses this to analyse newly loaded files for lines of code that can have breakpoints to resolve them. Before doing its magic, it calls the already present handler, nominally, the built-in PHP one that converts a PHP script into byte code that the PHP engine can run.
OPcache uses the handler to see whether it sees a file being converted (parsed) for a second time. If it is in its cache, it doesn't call PHP's original compile handler again but instead returns the byte code from its cache.
If OPcache is loaded first and then Xdebug, the following sequence occurs:
-
OPcache replaces the compile file handler with opcache_compile_file
, and remembers the previous one, php_compile_file
.
-
Xdebug replaces the compile file handler with xdebug_compile_file
, and remembers the previous one, now opcache_compile_file
.
In this situation, when PHP runs the compile file handler, it first calls xdebug_compile_file
, which then calls opcache_compile_file
and all is well.
The process reverses if OPcache is loaded last:
-
Xdebug replaces the compile file handler with xdebug_compile_file
, and remembers the previous one, php_compile_file
.
-
OPcache replaces the compile file handler with opcache_compile_file
, and remembers the previous one, now xdebug_compile_file
.
When PHP runs the compile file handler, it calls opcache_compile
first. OPcache checks whether it has seen the file already and, if not, calls the previous handler (xdebug_compile_file
), but if it has seen the file already (the second request through a php -S server), it does
not call the previous compile file handler.
Typically, that is what you want, as compiling files is expensive. However, because it does not call th