XDebug & PHPStorm Stopping at First Line
I have XDebug setup with PHPStorm and it breaks at the first line of my project, however ‘Step Over’ does not do anything, and setting breakpoints anywhere else in the project fails.
I am using a remote debugging setup, my XDebug config is as follows
zend_extension="xdebug.so"
xdebug.mode=debug
xdebug.client_host=localhost
xdebug.client_port=9003
xdebug.log=/tmp/xdebug.log
xdebug.log_level=10
xdebug.idekey=PHPSTORM
I then connect to the remote machine using an SSH tunnel. The connection to PHPStorm is made and it breaks at the first line.
If I then hit ‘Step Over’ to move to the next line, the debug session ends. I also have breakpoints set in my project that should be hit, but are not. The path mappings are set correctly.
I can also map the individual file in the nested tree that opens, it doesn't change the fact that the breakpoint never gets hit. If I delete the server, when I make the request I am asked to setup the path mappings again - I can do this but nothing changes.
I have checked that the files do indeed match by using SCP to grab them and diffing, I have made sure the composer lock is the same, the composer version is the same (In an attempt to ensure it wasn't being caused by a vendor mismatch).
I am using PhpStorm 2023.3.4 and Xdebug 3.3.1. I have made sure also that opcache is disabled.
At this point I have tried everything I can think of, even setting the XDebug logs to level 10, which doesn't reveal any errors.
Please sign in to leave a comment.
In my experience when only the first line is hit by the debugger, not your other breakpoints, your path mapping is incorrect and it fallsback to a break on the first line. This behavior is a setting in your PHP settings: “Force break at first line when no path mapping specified”.
The reason it is breaking at the first line is because I have it set to, if I remove it no breakpoint is hit at all.
I understand it is normally a path mapping issue, however I can't see how.
The first is my settings, the second is the remote and local server showing the same path for a file. I have even set it for that file specifically and nothing.
Hi there,
Try enabling extra logging from the IDE side – it should show how it matches the paths etc.
https://www.jetbrains.com/help/phpstorm/troubleshooting-php-debugging.html#collect-debugging-logs
Hey,
I have tried enabling more verbose debugging but it didn't help me, I will share the logs in case someone else can see something I can't.
With ‘Break at First Line' Disabled.
This goes on for quite a while, it seems like it's checking it against every file… so it should eventually find the correct file?
Toward the end of the log file I also get this message thousands of times.
Actually it appears there are 100,000+ of that message, but the log file ends like this.
Also according to the Xdebug docs
And it appears to me that it is set correctly, so that should rule out path mapping issues?
Theropfather
Not always / not directly.
I mean: normally I do not have any issues with setting the web page debug. But recently (a few weeks ago) I was working on a Laravel project, doing the artisan commands (parsing data, storing it in the DB etc) and CLI debug works fine as usual. But when I have started to work on the web interface .. I had issues with setting it up – it could not stop on breakpoints, at all. At the same time – it still worked fine in another project (all local, PHP 8.2, Xdebug 3.3.1, Windows 10 & IIS web server).
I'm not sure what did it, but the next IDE session the same thing (my latest IDE settings changes) worked from first attempt. Not sure if a PC restart helped or PhpStorm one (as I do not remember now if it was on the same day or on the next one – I'm shutting down my PC every night).
So …
It's possible that one of the settings (from the last point) do interfere. And that's why the logs from the IDE side of things might help (in case they are “looking for the wrong stuff”)
Here are the screenshots requested, I had already posted the PHP Servers info above, but this time I've included some more of the path mappings.
And here are the debug settings.
As noted in above posts, setting Break at first line does in fact break at the first line, but nothing else works after that, even stepping to the next line in index.php, which is where the breakpoint is anyway?
I've also tried disabling Resolve breakpoint if it's not available, force break at first line when no path mapping, force break at first line when a script is outside and enable return function value debugging.
Thanks.
1. Do you have any deployment entries configured for this project? If yes – do you have one that is marked as default?
2. Regardless of the above – try disabling this option: “Settings/Preferences | PHP | Debug | Detect path mappings from deployment configurations”. Any difference?
If not – try deleting the “PHP | Server” entry, maybe even restart the IDE at this point, and then try to debug (so that IDE will create a new entry). This is in case if it still has any “links” to the old info…
If still the same – then you would need to look into the logs (no better ideas from me ATM). If you do not want to share them here – then you will have contact PhpStorm Support by creating a Support Ticket via that big blue “Submit a Request” button at the top where you can privately provide all the info and JetBrains staff will look into that when they have time (will be busy now, shortly after a release).
Xdebug log – what command the IDE issued. Where breakpoint was set (what file and line). Was it confirmed by Xdebug? etc.
If it was set correctly – does Xdebug tries to stop there? Because if it does not try then it's either does not see it (breakpoint was not set) or an issue in actual Xdebug…
P.S. What's your PHP and Xdebug versions? If it's latest Xdebug v3.3.1 and PHP is 8.2 or older – try how Xdebug 3.2.x will do.
I do have deployment entries set, and yes one is marked as default.
With Detect path mappings from deployment configurations disabled, nothing changes.
I removed the servers, which I have done before in an attempt to fix and restarted and was presented with the expected window.
Accepting this path mapping, of course does not change anything.
Interestingly though, when I looked at the deployment import it shows.
No suitable deployment configurations was found. I'm unsure why that is, because the deployment path mappings are correct
Regardless, manually or deployment, same result. No breakpoints hit, first line can be hit but nothing else, not even stepping after that.
I will take a look at the IDE logs, since the Xdebug logs are above for anyone to look at. If I don't see anything I'll try to anonymize the logs and post them.
Here are the IDE logs that are relevant.
I don't know what to make of this, it seems to me, the mapping is correct, everything should work but I assume when I click ‘Step Over’ or ‘Resume’ it results in ‘Stop reading’, ‘Stop writing’, ‘Connection stopped’ and then socket closed.
I am in the process of installing 2024.1, in a hope that it may randomly fix this issue.
1. Please remove/comment out this line and try to collect Xdebug log again. It is indeed has way too much not needed details (for me at least). Default level (which is “7” IIRC) is enough.
2. Please create a separate file (e.g.
xdebug-index.phpand place it in yourpublicfolder). Then place a simple code similar to this one:and place breakpoint on the
$b = 3;line. Simple code (one simple instruction per line) + break on the 2nd executed line of code.Now try to debug this file directly (
site.com/xdebug-index.php)Collect the logs for this one actually.
3. OPCache… can you either disable loading it completely (so it's not listed in PHP info at all) or ensure that it is loaded before xdebug one (should be by default anyway IIRC… but hey)
4. Remove any other breakpoints (use Bookmarks toolwindow – it lists all stuff) and watches (to avoid irrelevant for us evals)
P.S. IDE side log seems OK to me.
Do the Xdebug log (it should be quite short if all above is done) and post it here.
I've lowered the logging level to default.
I did as you asked and created the xdebug.php file in both locations (local and server) and set a breakpoint on line #2. Here is the Xdebug log for that exchange.
Command is not available seems promising, however that is for eval not step_into (which I never clicked btw).
Also, I tried fully removing opcache instead of just disabling it, and I get a 502.
It gives a coredump error, and I checked and dmesg shows
This appears when I comment out zend_extension=opcache.so entirely.
Just the make the above clear
When I change
10-opcache.inito look like thisPHP-FPM segfaults, and the segfault is in xdebug.so
When set to this
There is no segfault, no 502 and the website works as expected (sans the debugging)
**EDIT**
This is no longer the case?? I uninstalled and reinstalled opcache, and now I don't get the segfault either way - debugging is still busted though :)
It's solved, I fixed it, I'm both overjoyed and annoyed.
After running
/usr/sbin/php-fpm -vit showedXdebug must be loaded as a zend_extension.The issue is so simple, but so easy to hide. I had set in my
php.iniextension=xdebugalongside the20-xdebug.iniafter removing the faulty lineextension=xdebugit all works, perfectly.Thanks so much to everyone for the help, especially Andriy!!
Theropfather
That was unexpected…
If you have a bit of time, can you do the following:
extension=xdebugchangexdebug_info();function will printTBH I was expecting Xdebug to detect such scenario… (cannot say if it's possible though, since I'm not into PHP source/internals)
Sure thing!
Doing what you asked,
xdebug_info();displays the following.There is nothing of interest hiding below where the screenshot cuts off, just standard PHP build info, so I didn't take a second one.
Yeah, it's strange that there is no mechanism for it to detect that it's running extension instead of zend_extension. I mean technically it is there, if you manually run PHP-FPM, but not many users do that or even know you can - strange one to handle.
This comment just appeared (was on moderation all this time I guess…)
Not important any more (the issue is found and resolved) but anyway: the script execution was already complete when that eval command was sent (unless it's a “write to log” race condition of some kind)… No breakpoints attempted in that log.
Wow!
This saved my life! Had already spent hours on this one, unsuccessfully!
I was about to give up although I knew I wasn't far so I kept looking.
Thanks you very much.