PhpStorm not reacting to xdebug
I have a weird issue that has me stumped.
I have had PhpStorm working with Xdebug flawlessly for the last 6 months in my current environment.
Today, it just stops working.... everywhere....
When I refresh a page in Chrome (with extensions installed and set to debug, and PhpStorm listening to debug connections ) the page will hang. If I disable any part of the debugging, the page load as expected. I have checked all settings multiple times on multiple servers/platforms, rebooted everything. I even updated my PhpStorm ... no dice.
All environments I am trying to debug were working fine yesterday, and not today.
The server environments are
- Linux/ Apache 2.4.29 / PHP 5.6.33 / xdebug 2.5.5
- Linux/ Apache 2.4.33 / PHP 7.2.5 / xdebug 2.6.0
- Windows/ Apache 2.4.33 / PHP 7.2.5 / xdebug 2.6.0
With PHPStorm 2017.?? => 2018.1.4 running on windows 10
My first thought was a firewall being activated by our corporate SOC lastnight ... but the log appears to show that the server is successfully connecting to PHPStorm on my windows box.
I have run out of ideas. Any thoughts on what to check would be greatly appreciated!
All environments have slightly different settings, but are showing the same results. The following sample data is from env #2
NOTE: xdebug.remote_connect_back is being used, so the below remote host error is irrelevant
Note: in addition to the settings below, breakpoints are set in multiple reliable locations.
This is the complete log before the browser hangs. Log never closes, PhpStorm never reacts and browser keeps trying to load.
Please sign in to leave a comment.
If it's a firewall .. then it should be some new to me stuff ...
But you may try to disable the firewall completely during a test .. and use Windows apps/host only (no Linux).
Same with antivirus -- try disabling it if you have some Internet Security package or whatnot.
No better suggestions right now...
I had a similar problem where after upgrading from 2018.2.2 -> 2018.2.4 caused xdebug not to work. The problem was caused by windows firewall.
When you start your very first debug session after upgrading, there is a firewall confirmation popup. something like the image in OP https://superuser.com/questions/1104599/firewall-pop-up-notifications-wont-go-away-windows-10
Make sure public network checkbox is checked.
that fixed it for me.
So using the manual remote debugging doesn't seem to work either.
I can see the breakpoints in the xdebug log on the VM.
But it doesn't ever stop at them.
Okay, this was my fault. I must have missed an update because apparently the XML schema of Xdebug changed at some point and then PHPStorm had to change. So upgrading to 2018.3.x fixed this problem for me.
I had the same issues above using PhpStorm 2018.1.2 and 2018.1.7.
Upgrading to 2019.3 fixed the problem for me.
Hi there,
>If I disable any part of the debugging, the page load as expected.
What do you mean here?
What kind of code is there? Can you debug very simple code where you just add few int variables into 3rd (each command on separate line)?
Will it make any difference if you increase the max number of simultaneous xdebug connections from 1 to 3?
Can you terminate the script from within the IDE?
Thank You for the thoughts and taking the time to reply!
>What do you mean here?
When the IDE is listening for a connection AND xdebug helper is in debug mode, the browser hangs.
When either is disabled, the page loads as expected.
>Can you debug very simple code where you just add few int variables into 3rd (each command on separate line)?
All my debugging test have been simple, using vars, functions, and output that are consistently paused on. I have also tried on pages I know are path mapped.
Here is an example of the code I have tried.
>Will it make any difference if you increase the max number of simultaneous xdebug connections from 1 to 3?
I had tried setting it to 10 before, just tried 3... same results
>Can you terminate the script from within the IDE?
No option to terminate the script is available, as the IDE has no reaction to the xdebug session. The debug window never appears, nor is View -> Tool Windows -> Debug ever enabled.
No changes so for.
Thanks for the ideas though!
One thought I had this morning...
I am still not 100% convinced the firewall isn't blocking something, but I don't know enough about firewalls to know if there is a way to find out ....
Perhaps it is allowing the initial connection, but somehow blocking data transmission?
So the effect would be, xdebug would activate because it has received the Cookie, it would successfully connect to PHPStorm which would instruct xdebug to break on a line. So the server breaks on the line as instructed, sends data to PHPStorm. The firewall blocks the data transmission, so PHPStorm never receives the signal to activate the debug tools. Causing the browser to appear locked up, but rather it is just paused at the correct breakpoint, and PHPStorm never hears back from the browser so it just sits there, assuming the breakpoint is never hit.
The factor that doesn't make sense to me is, I would think the firewall would block the initialization process as well as the data, but perhaps xdebug is using different protocols or settings to do the handshake which make it past the firewall.
Does that make any sense?
>No option to terminate the script is available, as the IDE has no reaction to the xdebug session. The debug window never appears, nor is View -> Tool Windows -> Debug ever enabled.
If you enable extra debug log on IDE side as well -- will it show anything?
https://intellij-support.jetbrains.com/hc/en-us/articles/207241115-How-to-Collecting-PhpStorm-WebStorm-debug-Logs
>Perhaps it is allowing the initial connection, but somehow blocking data transmission?
TBH -- extremely unlikely ... because:
Here is my test file:
PhpStorm 2018.1.4, Windows 10 x64; PHP 7.1.17 nts x86; Xdebug 2.6.0.
Here is the actual xdebug.log (breakpoint was at $b = 2; line; After that I just hit "Resume" button. It was CLI debug (PHP Script type of Run/Debug Configuration)
The same but via browser (PHP 7.2.5 nts; IIS)
The relevent IDE log
Server side log remains the same
We are definitely not receiving the data from the server at the breakpoints.
> 1 + 2
That was my exact reasoning for discounting the firewall initially.
However, being that we have a disconnect at the same location from 3 unique independent servers, and that it happened with 2 different versions of PHPStorm. I think the problem is either firewall, antivirus or network blockages. Since firewall and antivirus will be checked by the same process (McAfee) I'll start there.
Being that McAfee is controlled by Corporate IT through McAfee, it may take some time to get that one disabled. I did start that process today...
Thanks again for the time and ideas you gave Andriy! You helped narrow it down further.
I'll keep you posted.
A quick update for you.
We are reasonably sure it isn't a firewall, antivirus, or something on my local environment, as we disabled everything we could find and it still wouldn't connect. We are looking into a recent networking security rule change that may have effected it.
However, a much more useful find...
I did some tinkering around, and tried a manual debugging session. IT WORKED!!!
steps:
-Find Edit Configurations (use search or use the debugger drop down)
-Press add button
-Select PHP Remote Debug
-Selelct a server -- I just set it to the existing server I have been using for my current environment.
-Enter your IDE key used by Xdebug helper extension
-Apply
To run:
- Select the debug config you just created (mine is a generic 'manual' configuration I just use as default for whatever file I am working on at the time)
- Run the debugger (click the bug) -- this will manually open a debug session
- Load the page with xdebug enabled and break points set
Slightly more involved then just listening for debug sessions, but not so cumbersome that it won't work till we figure out the original cause.
Anybody have any suggestions for why the automatic debugger system won't respond, but this manual connection seems to work correctly?
Thanks!
P.S. The environment from above hasn't changed significantly
>Anybody have any suggestions for why the automatic debugger system won't respond, but this manual connection seems to work correctly?
Based on the logs you have provided before -- communication happens -- IDE talks to Xdebug and it responds back. Just then after few initial commands it breaks for no obvious reason (and I have no idea at what side it's happening: Xdebug or IDE).
Based on my experience -- there should be no difference on how the session was invoked: via cookie (set by browser extension) or via GET parameter (added to URL by IDE).
I'm having a similar issue where, if I don't have any breakpoints set, but debugging on, it will break all requests from the browser. They seem to return 200 OK, but with no content.
I tried turning on "Break at first line in PHP scripts", and it correctly pauses at that spot, but when I hit continue, it again fails to do anything after a while.
I can step through the code, and everything seems to work fine as I'm stepping through it, but as soon as I hit the play button, it fails.
Here is a copy of my xdebug.log:
The thing I find interesting, is the eval -i 31 line, that has the base64 encoded string that says "IDE_EVAL_ERR". Not sure what causes that, but it seems to cause everything else to fail.
<pre>
Log opened at 2018-06-20 16:41:54
I: Connecting to configured address/port: 10.131.41.210:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///gui/dsweb/webroot/index.php" language="PHP" protocol_version="1.0" appid="21958" idekey="PHPSTORM"><engine version="2.2.3"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2013 by Derick Rethans]]></copyright></init>
<- feature_set -i 1 -n show_hidden -v 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="1" feature="show_hidden" success="1"></response>
<- feature_set -i 2 -n max_depth -v 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="2" feature="max_depth" success="1"></response>
<- feature_set -i 3 -n max_children -v 100
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="3" feature="max_children" success="1"></response>
<- feature_set -i 4 -n extended_properties -v 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="4" status="starting" reason="ok"><error code="3"><message><![CDATA[invalid or missing options]]></message></error></response>
<- feature_set -i 5 -n notify_ok -v 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="5" status="starting" reason="ok"><error code="3"><message><![CDATA[invalid or missing options]]></message></error></response>
<- stdout -i 6 -c 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="stdout" transaction_id="6" success="1"></response>
<- status -i 7
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="status" transaction_id="7" status="starting" reason="ok"></response>
<- step_into -i 8
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="step_into" transaction_id="8" status="break" reason="ok"><xdebug:message filename="file:///gui/dsweb/webroot/index.php" lineno="27"></xdebug:message></response>
<- eval -i 9 -- aXNzZXQoJF9TRVJWRVJbJ1BIUF9JREVfQ09ORklHJ10p
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="eval" transaction_id="9"><property address="140737488338432" type="bool"><![CDATA[0]]></property></response>
<- eval -i 10 -- aXNzZXQoJF9TRVJWRVJbJ1NFUlZFUl9OQU1FJ10p
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="eval" transaction_id="10"><property address="140737488338432" type="bool"><![CDATA[1]]></property></response>
<- eval -i 11 -- KHN0cmluZykoJF9TRVJWRVJbJ1NFUlZFUl9OQU1FJ10p
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="eval" transaction_id="11"><property address="140737488338432" type="string" size="13" encoding="base64"><![CDATA[MTAuMTMxLjQxLjIxNQ==]]></property></response>
<- eval -i 12 -- KHN0cmluZykoJF9TRVJWRVJbJ1NFUlZFUl9QT1JUJ10p
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="eval" transaction_id="12"><property address="140737488338432" type="string" size="3" encoding="base64"><![CDATA[NDQz]]></property></response>
<- eval -i 13 -- KHN0cmluZykoJF9TRVJWRVJbJ1JFUVVFU1RfVVJJJ10p
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="eval" transaction_id="13"><property address="140737488338432" type="string" size="40" encoding="base64"><![CDATA[L3BjYXBfaW1wb3J0L2dldF9jb25uZWN0aW9ucy5qc29uP3BhZ2U9MA==]]></property></response>
... snip breakpoints ...
<- stack_get -i 26
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="stack_get" transaction_id="26"><stack where="{main}" level="0" type="file" filename="file:///gui/dsweb/webroot/index.php" lineno="27"></stack></response>
<- stack_get -i 27
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="stack_get" transaction_id="27"><stack where="{main}" level="0" type="file" filename="file:///gui/dsweb/webroot/index.php" lineno="27"></stack></response>
<- context_names -i 28
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="context_names" transaction_id="28"><context name="Locals" id="0"></context><context name="Superglobals" id="1"></context></response>
<- context_get -i 29 -d 0 -c 0
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="context_get" transaction_id="29" context="0"><property name="$Dispatcher" fullname="$Dispatcher" type="uninitialized"></property><property name="$failed" fullname="$failed" type="uninitialized"></property></response>
<- context_get -i 30 -d 0 -c 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="context_get" transaction_id="30" context="1">
<property name="$_COOKIE" fullname="$_COOKIE" address="140737352829808" type="array" children="1" numchildren="2" page="0" pagesize="100">
<property name="DSWEB" fullname="$_COOKIE['DSWEB']" address="140737352830528" type="string" size="26" encoding="base64"><![CDATA[... snip ...]]></property>
<property name="XDEBUG_SESSION" fullname="$_COOKIE['XDEBUG_SESSION']" address="140737352830856" type="string" size="8" encoding="base64"><![CDATA[UEhQU1RPUk0=]]></property>
</property>
<property name="$_ENV" fullname="$_ENV" address="140737352831320" type="array" children="0" numchildren="0" page="0" pagesize="100"></property>
<property name="$_FILES" fullname="$_FILES" address="140737352831096" type="array" children="0" numchildren="0" page="0" pagesize="100"></property>
<property name="$_GET" fullname="$_GET" address="140737352828088" type="array" children="1" numchildren="1" page="0" pagesize="100">
<property name="page" fullname="$_GET['page']" address="140737352828744" type="string" size="1" encoding="base64"><![CDATA[MA==]]></property>
</property>
<property name="$_POST" fullname="$_POST" address="140737352829584" type="array" children="0" numchildren="0" page="0" pagesize="100"></property>
<property name="$_REQUEST" fullname="$_REQUEST" address="140737352831544" type="array" children="1" numchildren="1" page="0" pagesize="100">
<property name="page" fullname="$_REQUEST['page']" address="140737352828744" type="string" size="1" encoding="base64"><![CDATA[MA==]]></property>
</property>
<property name="$_SERVER" fullname="$_SERVER" address="140737352831864" type="array" children="1" numchildren="74" page="0" pagesize="100">
... snip ...
</property>
</response>
<- eval -i 31 -- JEdMT0JBTFNbJ0lERV9FVkFMX0NBQ0hFJ11bJzE4YmMyYTQxLWYyYzgtNDAzZS04NTk4LTQyY2YyYWUyMTQ2ZSddPShpc3NldCgkdGhpcywkdGhpcy0+dGVtcGxhdGUpKT8oJHRoaXMtPnRlbXBsYXRlKToiSURFX0VWQUxfRVJSIg==
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="eval" transaction_id="31"><property address="140737488338432" type="string" size="12" encoding="base64"><![CDATA[SURFX0VWQUxfRVJS]]></property></response>
<- run -i 32
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="run" transaction_id="32" status="stopping" reason="ok"></response>
<- run -i 33
Log closed at 2018-06-20 16:41:59
Log opened at 2018-06-20 16:42:44
I: Connecting to configured address/port: 10.131.41.210:9000.
E: Could not connect to client. :-(
Log closed at 2018-06-20 16:42:44
Log opened at 2018-06-20 16:42:46
I: Connecting to configured address/port: 10.131.41.210:9000.
E: Could not connect to client. :-(
Log closed at 2018-06-20 16:42:46
Log opened at 2018-06-20 16:42:46
I: Connecting to configured address/port: 10.131.41.210:9000.
E: Could not connect to client. :-(
Log closed at 2018-06-20 16:42:46
... snip hundreds of Could not connect messages ...
</pre>
I have this same problem and assumed something changed in our development environment. But now I think something has changed with PHPSTORM and/or XDEBUG.
But essentially I was working great with debugging et al and then one day I had the same problems as the op.
If I enable listening for Xdebug connections all browser requests hang, if I turn off listening for Xdebug then the browser request completes. If I enable break at first line, it does but pressing "continue" throws me to the hanging.
I am on a Mac and have disabled the firewall with no change to the result and my development box is a vagrant vm on my machine so the requests are not to external hosts.
I guess I'll try the manual debugging solution for now, but if anyone has a better one I would appreciate it.
I just ran into this issue. It appears to be fixed after I removed all existing breakpoints and started setting them again. The issue started after upgrading php and phpstorm. Not sure what the root cause was.
Had the same issue. Upgrading fixed it for me as well
Same issue here using the zero-config setup. I'm on version 2020.1 (Mac). It was working before I updated.
Phpstorm doesn't seem to break anymore. When I log xdebug I can see it making a connection to the client. But there is always this error (donno if relevant):
When I enable a manual xdebug session, phpstorm breaks correctly.
Tried: restarting everything, removing all breakpoints... nada.
Any help/pointers appreciated.
Could you please show the full XDebug log?
This is the zero-config connect (not working):
This is the one working (manual config):
@kriboogh
>Phpstorm doesn't seem to break anymore. When I log xdebug I can see it making a connection to the client. But there is always this error (donno if relevant):
>When I enable a manual xdebug session, phpstorm breaks correctly.
You may ignore this line -- that functionality is available in Xdebug 2.8 and newer while yours is 2.7.2.
>This is the zero-config connect (not working):
1. Show your "PHP | Servers" entries as well as PHP Debugger settings from PhpStorm (need to see real screenshots with real text, not edited/redacted one).
2. What URL are you trying to debug when it does not work? (same as above: real URL)
3. Please clarify what exactly do you mean by the "manual session" -- screenshots are more than welcome.
Ok, so I figured it out, the servername was added in the config of our docker setup, so I had to rename the server in phpstorm config the same. works now.
@kriboogh
First of all: DBGp Proxy is completely irrelevant here: 1) you do not need it for local dev (only for real remote with multiple devs at the same time); 2) it requires the actual proxy software to be installed 3) it still will require extra step in IDE to be used.
Now back to the issue:
1. Your failed debug session has completely different server name ... which is made manually. It has to be either your some OTHER project (current or past) or whatever.
For failed session it is reported to be federale-pol*****
Check your ENV variable -- PHP_IDE_CONFIG.
Is that a docker .. or local web server (same host OS)? Such variable is normally used for certain CLI debug (mainly remote .. or if it's initiated not from IDE) or when a Docker is used and you cannot be bothered with configuring web server properly to have proper web site name.
2. The second issue -- related to the first one.
2.1) You have only one "PHP | Servers" entry and it's for p***e.lokal.host
2.2) At the same time "Settings (Preferences on macOS) | Languages & Frameworks | PHP | Debug | Ignore external connections through unregistered server configurations" -- you have that option enabled ...
So now you see: debug session started for entry with a name of fderale*** .. but your ONLY Server entry is for p*** .. and you disallowing entries for the unregistered server name.
IDE sees debug connection for unknown server/domain ... and since it has been told to ignore it ... it does what it has been told: ignores it. (P.S. It may have worked before because the "ignore" option did not always work properly before, but it has been fixed for 2020.1 -- https://youtrack.jetbrains.com/issue/WI-44914)
Solution: uncheck that option and try again to see how it goes.
Another possible solution -- look for PHP_IDE_CONFIG environment variables and remove it.
Yes, the PHP_IDE_CONFIG is also present for working session, but since the session has been initiated via IDE with server/domain name already there, it knows what to use.
That's all what I can say for the moment based on the limited info about your setup from your logs/screenshots.
Andriy Bazanov thanks for the info. I renamed the server now and now it works.