xDebug stops working after any first breakpoint

Hi there,

TBH -- no solid ideas.

1. Try downgrading/upgrading Xdebug (what PHP and Xdebug versions do you use right now?)

2. What Xdebug log has to say about debug session? Maybe xdebug crashes ...?

3. Try disabling other PHP extensions for now (try on simple script so only core extensions enabled)?

4. Try with OPCache disabled.

Hi,

I experienced the same issue and spent two days fixing it.. The problem turned out to be related to the following:

When using PHP + xdebug 2.4.x, debugging worked fine. After rebuilding my docker container, xdebug 2.7.1 was installed instead which broke the debugging process like you describe.

I was using PHPStorm 2018.x, after upgrading PHPStorm to the latest 2019.x version, debugging started working again :)

Hope this helps someone!

Thank you Milan, that worked for me.

Notice that xdebug 2.4.1 will not install if you're using PHP 7.2, the minimum version for that will be xdebug-2.6.0.

For the rest Milan's answer is correct

NOTICE: If you have Xdebug 2.7.x or newer then you need to use PhpStorm 2018.3 or newer (due to changes in Xdebug protocol).

If your IDE version is older than that and you do not want/or cannot upgrade your IDE, then you have to stick to Xdebug 2.6.x or older.

Thank for you answer Andriy Bazanov,

The problem is : When I use xdebug 2.6.0 with my PHPStorm 2018.1.6. It's simply does not work at all (on Validate debugger i get a Read timeout error)

And on 2.7.0 the bug presented here happens.

>The problem is : When I use xdebug 2.6.0 with my PHPStorm 2018.1.6. It's simply does not work at all (on Validate debugger i get a Read timeout error)

Incompatible Xdebug with your PHP version? Does PHP load when that 2.6.x is in use? Maybe it throws some errors on startup...

Cannot speak about 2018.1 (as I may not have used 2.6 version back then) but 2018.2 worked with 2.6 just fine for me for sure. I'm on Windows 10, PHP nts builds, 32-bit ones back then (using x64 builds now).

Nevermind.

It was an issue on my side, the debugger was still runing when I tested de validation process, so the read timeout error happened. I just switch it off. And restart it. Then xDebug was finally fully functionnal, happy ending, but hard fight.

In my opinion, PHPStorm should tell us in this debug panel which version of the debugger we shouldget (Compatibility with PHP And PHPStorm). It will save us more time.

>In my opinion, PHPStorm should tell us in this debug panel which version of the debugger we shouldget (Compatibility with PHP And PHPStorm).

That sounds like I good idea -- feel free to make Feature Request ticket at the Issue Tracker

Although, considering that current IDE version (2019.3 has been released today) support those old and new Xdebug versions, it's rather unlikely that devs will consider implementing it (and they will not make special "update" builds for old IDE versions).

I started experiencing this same problem last night; can only stop on a single breakpoint, and stepping does not work after that (and I see only a white page). For me, this was also an "out of the blue" development. I didn't mess with my VM, or my server, or any settings, it was simply working fine one moment, and in the next, it wasn't.

PHPStorm: 2020.2

PHP: 7.4.10

XDebug: 2.9.5

My xdebug settings:

xdebug.remote_enable = 1
xdebug.remote_host = 192.168.33.1
xdebug.remote_connect_back = 1
xdebug.remote_port = 9000
xdebug.remote_autostart = 1
xdebug.remote_cookie_expire_time = 0
xdebug.remote_log = /home/shmax/shmax.com/logs/xdebug.log
xdebug.remote_handler = dbgp

xdebug log:

https://gist.github.com/shmax/876f6a10f84e4fa72344dc270590a864

I'm at my wit's end. Any advice?

@Shmax

As per Xdebug log: it connected to IDE just fine, breakpoint is set for line 17.

How the code looks there (at the breakpoint)?

1) Maybe it never gets hit? Try placing it on another line, ideally some simple line (simple 1 line assignment). Basically -- try debugging very simple code first.

2) Will it make any difference if you do programmatic breakpoint (by adding xdebug_break(); in your PHP code)?

P.S. Restarting IDE/PC may help in such "suddenly stopped working for no apparent reason", even on Mac/Linux :)

P.P.S.

Just a side note/FYI:

xdebug.remote_host = 192.168.33.1
xdebug.remote_connect_back = 1

The value of remote_host is ignored when remote_connect_back is enabled. For you it does not matter as they both point to the same IP. This is fixed/improved in Xdebug v3

xdebug.remote_handler = dbgp

This option is obsolete since 2.9 (it's always dbgp internally) -- https://stackoverflow.com/a/63209405/783119

> How the code looks there (at the breakpoint)?

> 1) Maybe it never gets hit? Try placing it on another line, ideally some simple line (simple 1 line assignment). Basically -- try debugging very simple code first.

I don't blame you for confirming this kind of thing, but this is the same code base I've been working with for 10 years. It doesn't matter where I place the breakpoint, the behavior is the same: the breakpoint gets hit, then after that stepping doesn't work, and no further breakpoints are hit. To totally address your concern, I confirmed that putting a breakpoint on the very first line of my main index.php file has the same problem.

> 2) Will it make any difference if you do programmatic breakpoint

No, no difference. Same behavior; we stop after the first call to xdebug_break(), then we enter the broken state.

> P.S. Restarting IDE/PC may help in such "suddenly stopped working for no apparent reason", even on Mac/Linux :)

I've done that and more. I've restarted my server dozens of times. I destroyed my VM (I use Vagrant/VirtualBox), I've power-cycled my PC 3 or 4 times.

> The value of remote_host is ignored when remote_connect_back is enabled

> This option is obsolete since 2.9 (it's always dbgp internally) --

I know, I was just desperate and trying everything I could find. The issue happens even without these things.

Thank you kindly for your support. What are my next steps?

@Shmax

TBH: I do not really know what to suggest here:

- your Xdebug log shows nothing critical: stopped at line 4, breakpoint is set an line 17.

- IDE communicates well (nothing unusual at quick glance)

The best I may suggest right now:

- Create another simple file in the same project, call it directly and try to debug it instead:

<?php
$a = 1;
$b = 3;
$c = $a + $b;
echo $c, "\n";

- If it makes no difference: close IDE, go to the project folder and backup and delete .idea subfolder (project settings). Then launch IDE, use "Open" and point to the project root -- IDE will create new project from existing files. Now re-configure it (whatever is required to deploy/debug it) and try there.

- You may do the same with IDE settings (if previous step does noting)

- If still nothing ... maybe some remote TeamViewer session may help: seeing with own eyes the whole process + settings review may give some hints...

That looks like a fair experiment. I'll try it after work, and if still no luck I'd love it if we could do a TeamViewer session. I'll be in touch with more information. Thank you.

Your instincts were correct. If I blow away my .idea folder and let PHPStorm generate a new one, things start working again. Once I had copies of both corrupt and functioning .idea folders, I was able to use a diff tool to track the error down to a single expression in .idea\workspace.xml:

On the right is a fresh, functioning workspace.xml file.

On the left is the naughty one. The block outlined in green seems to be causing all the trouble. I have no idea which action generated that block or why it's breaking things, but if I delete it normal debug functionality returns.

Would you like me to open an issue?

@Shmax

"global $context" -- you must have got it as an entry in watch panel (as far as I understand it)

IDE tried to evaluate it and Xdebug returned an error (command #19 in the log). IDE still were doing other commands after that so it's not that it broke because of that or anything. But having "global" there is unnecessary and I cannot say if it may cause such issue.

Try to reproduce it again. If you can do that in a new project then yes, definitely report it to the Issue Tracker .

Andriy Bazanov I will certainly do that. Thanks very much for your patience and support.

Hi,

I don't know if I should create a new issue, but this one is the latest that I can find, and it is very similar to my problem. PHP 7.1.33 and Xdebug 2.8.0 in a container. So, no recent update. PHPStorm 2020.3 (Build #PS-203.5981.175, built on December 2, 2020) on Ubuntu 20.04 install in snap.

Only recently, Xdebug stop working in PHPStorm after the first connection. That means, I restart the PHP container, then the script stops at the breakpoint (and subsequent breakpoint etc.). However, after that, when I restart the page, Xdebug no longer works. Like nothing happens! There is nothing in Xdebug log, as if PHPStorm is not present when I visit the page. Xdebug still works in the console with PHPStorm. To make Xdebug works again in the web, all I have to do is to restart the container, and Xdebug works again, once, and I have to restart the container...

Any idea please, about where to look for?

@Hai-Nam Nguyen

Sounds like https://youtrack.jetbrains.com/issue/WI-56500 (comment from Xdebug author)

Either upgrade Xdebug to the latest version where the issue ix fixed (which is recommended anyway: 2.9.8 for Xdebug 2 and 3.0.1 for Xdebug 3) or try PhpStorm 2020.3.1 Preview build -- a workaround is present there.

NOTE If upgrading to Xdebug 3, it uses different config params now, so please check Xdebug: Upgrading from Xdebug 2 to 3 .

Thank you! I switch to the edge snap to use the preview release (it's the easiest solution), restart the PHP container and the problem is fixed.

I had the issue where stepping after a breakpoint was hit successfully caused the script to exit 0.

And followed the advice to remove the .idea folder and re-open the project folder. 

It worked great.

Thanks

Same problem.
Debugger stopped (correctly) at first breakpoint, but on F8 it immediately stopped, with a "Process finished with exit code 0".
I removed all .idea folders I could find and, also to be sure, .cache/JetBrains/* .
YES! Working. Thank you to all.
It was first time it happened, in 2 months of use.

Glad I found this thread. 

After reading the post by Shamax, I opened the debug window and removed the watches I had created previously..

Once they were deleted, everything started working again.

Thank you @Justin-Wright. Removed the watches and everything works fine now!

Running PHP 7.4.30 and Xdebug 2.9.8:
I hit the first breakpoint, hit step over, it jump to the calling file, instead of the next line. 
If I'm running PHP unit and have a break point, it completely fails with variables not being set.

Not sure I got you here. Which variables are not being set? Please share a screenshot of what it looks like.

Say I have a test that has some code like this.

$a = someObject->someMethod();
self::assertEquale(1, $a);

if I put a break point on $a = ... or in someMethod(), when the breakpoint is hit, I click continue run, the test will fail, saying $a wasn't set.

It's either that you are debugging some other version of code (if it were the case, it would be reproducible on run too, not only on debug), or some extremely aggressive caching mechanism changes the code. Is OPcache for CLI enabled?
If not, please submit a ticket with us (Help | Contact Support), and we'll take a look.

some problem here. Is a problem of certain phpstorm version.

For example 2022.2 have the problem. 2022.1 have not.

Thank you for your input, everyone! It's a new issue in 2022.2, you can find explanations and a workaround here:
https://youtrack.jetbrains.com/issue/WI-67891