Concealed Code
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 runningphp -v
or when looking atphpinfo()
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, nowopcache_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, nowxdebug_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 the previous compile file handler, that means that xdebug_compile_file
does not get run, which means Xdebug doesn't know anything about which lines of code can have breakpoints on them. It can not resolve them henceforth.
I can not work around this in Xdebug.
Luckily, there are workarounds:
-
Make sure to load Xdebug after OPcache — which is what the documentation says you should do.
-
Disable OPcache by setting
opcache.enable=0
. -
Don't load OPcache by commenting out the
zend_extension=opcached
line inext-opcache.ini
(or similar filename).
Loading Xdebug after OPcache is what you should strive for.
I usually name the xdebug.ini file 99-xdebug.ini and the INI file for OPcache 10-opcache.ini
, to enforce the loading order by respecting the sorting order of INI files as stored on the file system.
Alternatively, if you only have one INI file, make sure that Xdebug is listed after OPcache in this file, such as in:
zend_extension=opcache zend_extension=xdebug
From Xdebug 3.3, Xdebug will include a warning in the Diagnostic Log section of xdebug_info()
output to warn users that you should load Xdebug after OPcache.
As with all warnings in the HTML version of Xdebug's Diagnostic Log, there is also a link to documentation which explains what the problem is and what possible solutions are.
I have also made a video about the Xdebug 3 Diagnostic Log, which you can find on YouTube.
Comments
No comments yet
Add Comment