[SOLVED] Breakpoints are greyed out for being changed, while they were not #919
Comments
|
Hi. Thanks for the report.. Will dive into the logs to see why the second set of breakpoints isn't resolved. |
|
Hi. Very strange. How are you running PHP? Is it as a dev server (php -S), FPM, some other way? |
|
Hey @derickr, can you also look at this xdebug.log. Here we have two consecutive Xdebug sessions, on the same PHP process (same PID). Breakpoints being set on the same lines on both. The line breakpoints from the first session get resolved (389710001, 389710002) the breakpoints in the second session however do not get resolved (389710004, 389710005). |
|
Hi @zobo. I run it as the dev server. Docker- and fpm-based version shows stable breakpoint resolving, however. |
|
Hm. Can you also provide you phpinfo(). I'm interested if you are running NTS or TS mode of PHP. I'm currently testing on windows, but could be specific to Mac. |
|
Additional question. Which of the two configurations from launch.json are you using "Listen for Xdebug" or "Launch Built-in web server"? If you are using the first, how exactly are you starting the dev server, can you give me the command? Also the php code you provided. Is it in a file that is directly run or is it included with a require() or include()? |
|
|
Hi! TL,DR: Not a bug, and (shock horror) documented behaviour. I spend some time delving into this, and at first I could not reproduce this. On my side (Linux, PHP 8.1/8.2) with When I had another good look at your phpinfo() output PDF file, I noticed: This has OPcache loaded after Xdebug, which the documentation says you shouldn't do: And indeed, when I switched the loading order of the two zend extensions from: to I could reproduce this issue. Both Xdebug and OPcache override PHP's "compile a file" handler. Xdebug's uses this so that it can analyse newly loaded files for lines of code that can have breakpoints on it, so that it then can then resolve them. Before doing it's magic, it calls the already present handler. OPcache uses it to see if a file that is being parsed for a second time, and it is in its cache, it doesn't compile it again by not calling the already present handler. If OPcache is first loaded, and then Xdebug, the following happens:
This means that when PHP runs the "compile this file" logic, it first calls xdebug_compile_file, which then calls opcache_compile_file and all is well. If OPcache is loaded last, the process is reversed:
When PHP then runs the "compile this file" logic, it calls opcache_compile first. This checks whether it has seen the file already, and if not, calls the previous handler ( This is not something that Xdebug can fix. There are workarounds:
Curiously, your phpinfo() output allegedly already shows the right order ( I will see if I can add a warning for this to Xdebug's diagnostics log. |
|
Hello @derickr! Thanks for such a detail reply. I'll check whether it's my case ASAP. 🤝 |
|
HOW TO FIX:
OR
A word of gratitude: I can confirm that after I have
(VSCode-initiated server launch profile also is stable, since it relies on the system order of extensions loading) (php --version output does not correlate with the actual extension load order) @derickr Please have my respect about such a brilliant investigation! Closing the issue. |
|
I'm adding a warning too: xdebug/xdebug#901, and there is now more documentation: https://xdebug.org/docs/errors#DBG-W-OPCACHE to go with that log warning. |
nikitades
changed the title
PHP version: 8.2
Xdebug version: 3.2.2
VS Code extension version: 1.33.0
OS: Mac OS ARM
Screenshots of 1st run and subsequent 2nd run
Your launch.json:
{ "version": "0.2.0", "configurations": [ { "name": "Listen for Xdebug", "type": "php", "request": "launch", "preLaunchTask": "Enable XDebug", "postDebugTask": "Disable XDebug", "cwd": "${workspaceRoot}/src", "log": true }, { "name": "Launch Built-in web server", "type": "php", "request": "launch", "runtimeArgs": [ "-dxdebug.mode=debug", "-dxdebug.start_with_request=yes", "-S", "localhost:8080" ], "program": "", "cwd": "${workspaceRoot}/src", "port": 9003, "serverReadyAction": { "pattern": "Development Server \\(http://localhost:([0-9]+)\\) started", "uriFormat": "http://localhost:%s", "action": "openExternally" }, "presentation": { "hidden": false, "group": "", "order": 1 } } ] }Xdebug php.ini config:
Xdebug logfile (from setting `xdebug.log` in php.ini):
VS Code extension logfile (from setting `"log": true` in launch.json):
The text was updated successfully, but these errors were encountered: