I am working on an Ubuntu 18.04 system with PhpStorm version #PS-222.3345.135. I am on PHP 7.4.20 and Xdebug 2.9.8.
First off, when I am not running Xdebug on my web requests they work perfectly fine. When I attempt to step through execution with Xdebug, methods are exiting prematurely as I will show in the screenshots below:
First screenshot:
Execution is at the fist line of the launch() method. As such, pressing the Step Over button should bring execution to line 112 ($this->_state->setAreaCode($areaCode)); Instead, pressing Step Over prematurely exits the launch() method and brings the execution thread back out to the Bootstrap::run() method as shown below:
Note that there is no $response variable in the run() local scope as the launch() method was not allowed to return a value due to being exited prematurely. Pressing Step Over again will result in an exception being thrown by the $response->sendResponse(), as shown in the screenshot below:
To summarize, the issue here is that Xdebug is not stepping through code correctly. This issue didn't start occurring until this past week, and my path mappings for the project are the same as they were before.
This is happening for multiple PhpStorm projects, not just this one codebase. However I do have one PhpStorm project (with a much smaller codebase) in which stepping through code works fine (I upgraded the PhpStorm memory limit to 2GB as a result but that did not resolve anything).
Does anyone know why this would be happening?
It's PhpStorm 2022.2 issue (WI-67891 ticket).
https://youtrack.jetbrains.com/issue/WI-67891/Step-Over-broken-for-Xdebug-30-for-static-methods-and-private-properties-from-parent-classes#focus=Comments-27-6367485.0-0
Reason of the bug is found and fixed. Fix will be available in next minor update. Below is a technical summary of the issue for ones who curious about what happened:
Xdebug had a bug which is basically breaks further step_over commands by passing invalid eval commands. This bug is fixed in 3.1, but present in all older versions.
In 2022.2 We've implemented feature WI-56517 that shows __toString representation of the object in debug panel. This feature is implemented by passing eval((string)expression) command on start of debug sessions
It turned out that there are number of invalid inputs that happened to be produced by this command:
Private properties from parent class. Xdebug returns such properties in the format that is not suitable for plain evaluation https://github.com/xdebug/xdebug/blob/5af18430eb0b2c9574e903e6a9b9ef40c0ea7296/src/lib/var_export_xml.c#L441
:: instead of $this in case of static method (issue WI-67023)
Combination of these factors resulted into broken step_over. Both cases are fixed and will be available in next minor update. Sorry for the inconvenience and thank you for reporting the issue.
The aforementioned WI-67891 ticket is marked as fixed for 2022.2.1. You can try 2022.2.1 Preview now.
At the same time there are some reports that there are still some scenarios (not-yet-covered cases) where the debug still does not work as in previous version. Sadly there are more rather useless "me too" comments than "here is a code sample where it is still does not work" (as it requires time to make it, to see what may be causing it, be able to spot the difference in setup/environment etc).
Current solutions:
Upgrade to Xdebug 3.1 or newer if you can (the latest version right now is 3.1.5).
Disable Settings/Preferences | PHP | Debug | Evaluation | Enable '__toString' object view until confirmed as properly resolved. Do not forget to revert it back (this feature seems convenient for a quick-glance when debugging).
Stay on previous stable 2022.1.4 until the issue is confirmed as properly resolved.
Related
I've been experiencing an odd issue where something is getting cached somewhere and I'm not sure which item to blame and it's not only driving me nuts, but slows down my development workflow (and is VERY confusing).
The Problem: I save changes made to a PHP file and refresh my browser, however the changes do not show up.
Expected Behavior: The refreshed browser shows the updated file.
Actual Behavior: The most recent changes do not show up.
For some background, here are the possible factors that could be contributing to this problem:
Macbook Pro (16-inch, 2019, 2.6 GHz 6-Core Intel Core i7)
Mac OS (Monterey v12.5)
Chrome (v104.0.5112.79)
MAMP Pro (6.6 Build 33836), Apache (2.4.46), PHP (7.4.21), MySQL (5.7.34)
Xdebug
PhpStorm (2022.2 Build #PS-222.3345.135)
Gulp (v4.0.2) - Unlikely
BrowserSync (v2.26.14) - Unlikely
I work with WordPress although I don't think that's a factor here. Basically what is happening is I'll go to make a change to a PHP file, which could be just adding more code, fixing an error, or maybe even doing a var_dump, and when BrowserSync refreshes, the changes are not reflected, so the new code does nothing, or the error still exists, or the var_dump doesn't show up. Another example is once var_dump does work, if I go to remove that debugging line, it will still show up.
I haven't figured out a fix either, other than just repeatedly refreshing the browser or re-saving the file (sometimes after adding a few blank lines to "trick" whatever it is causing it to think the file has not been changed). This can happen with or without running Gulp/BrowserSync, but I don't want to rule this out as a potential part of the problem. It's behaving like the file has not been saved.
I sometimes will quit gulp and restart to see if that resolves the issue, although it's hard to tell if it has any effect since the problem persists for maybe 30 seconds and then I'm able to see the updated file.
This is something that has recently started to happen but doesn't happen consistently. Sometimes everything works as expected, but it's hard to tell what factors are contributing to when the issue starts happening again. Most recently it started again after I restarted PhpStorm (to apply an update).
Has anyone else experienced something like this? I'm not even sure what other information would be helpful, but would be happy to post more details if I'm missing something. Thanks!
Hopefully the following will give you enough to go on.
My setup
I'm using:
Windows 10 (now at build 19043.1288),
VSCode (v1.61.2) with
PHP debug (v1.21.1),
both Firefox and Google Chrome browsers,
XAMPP (v3.3.0)
Xdebug (now v3.1.1-7.4x86_64)
I'm also running Ubiquiti network controller, and BitDefender AV in the background.
PHP.ini
[Xdebug]
zend_extension = xdebug
;zend_extension = "c:\xampp\php\ext\php_xdebug-3.1.1-7.4-vc15-x86_64.dll"
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.client_port = 9000
xdebug.log = "c:\xampp\htdocs\j4\tmp\xdebug.log"
Problem
I've had VSCode/XAMPP/Xdebug working with Joomla 3 for well over a year without issues. I went away for a couple of weeks and when I came back I wasn't able to single step into any of the Joomla 3 modules/classes. VSCode would stop at breakpoint, but both single step and step into immediately went to the parent calling function.
Ah, I said to myself, probably Windows did something - may be a good time to upgrade to J4, as well as update my environment. Same problem. Stops at 1st breakpoint, won't single step or step into - it won't stop at subsequent breakpoints. Appears to single step in the core J4 modules. Stack appears normal - initialised variables can be inspected.
What I've tried
Everything! To keep this relevant - I've now installed a completely fresh, out of the box, unadulterated, XAMPP, Joomla4 and Xdebug (as recommended by Xdebug wizard). I've also temporarily disabled my AV (BitDefender). I don't have any firewalls on my PC, as I'm behind a network firewall.
Just in case, I did a deep virus scan and disk check - nothing.
Prior to installing everything fresh, I was able to get an Xdebug log file, but now I can't. I also noted that the breakpoints wouldn't reset - I'd remove all the BPs and they'd come back on next run. I'd have to stop and restart the PHP debug in VSCode to make them go away.
I suspect that the latest Windows updates (or maybe the last few), did something to my dev environment.
However, it's also possible that I've missed something stupid in the setup, as I've been round the circuit several times already, and my head isn't functioning as it should.
Where I need help
I'm now at a loss at what to try next - any suggestions? If no-one else can reproduce this - it means something in my system has glitched, any help would be appreciated.
Update 1
I discovered that a v2 of Xdebug had crept into my php/ext directory - not too sure how - and that was why I wasn't able to get a log file to work. I now have the correct version (3.1.1) of Xdebug installed and working. The single step issue, however, remains.
I now have a log from VSC debug console as well as from xdebug.log: see here
One thing I observe is that there are many errors associated with deprecated functions - I would have expected them to be warnings and not errors!
There are also numerous cases of "error evaluating code".
I have highlighted the place where the code stopped in the logs with "************". I don't know if this is expected or normal, but it does seem to occur a short time before the breakpoint stop - line 431 vs line 651 in the debug console log.
Update 2
Just in case anyone has any interest - I installed the latest version of Eclipse IDE with PDT. Used exactly the same XAMPP/htdocs directory as before - and Xdebug works as expected. No issues with single stepping.
This means, I believe, that Windows, XAMPP, Xdebug and Joomla can be ruled out as culprits, as these are common to both environments. Conversely, it also means that there's something going on with VSCode, or at least with my particular VSCode setup.
Breakthrough (I think!)
It appears that a couple of variables (e.g. $this->missingclasses) I had put into the watch window were causing the problem. I suspect that over the course of a few VSCode updates the persistent internal objects associated with those variables had glitched/corrupted. When I deleted the offending variable watches - single step started to work again.
After seeing that that worked, I was able to put the watches back and single stepping worked as expected. Putting the same watched variables into Eclipse had no effect on single stepping.
Just for good measure, I also deleted and reinstalled PHP Debug - although I'm pretty sure the watched variables, that couldn't be evaluated, were the real issue here.
I will leave this a couple of days, and then I'll close this with a suggested solution
As the title suggests, in some situations I step through the Magento 2 code, only for it to go to Magento\Framework\Session\SessionManager::writeClose(), thus calling session_write_close() and terminating the application immediately. The Call Stack is practically empty, so I can't see what is calling this. However if I insert a breakpoint and continue from there, it loads the website as if nothing has happened.
It only seems to occur on Magento 2 websites where it would suddenly terminate in such a fashion, however I'm not sure if it could be an issue with xdebug, Apache, or PHP-FPM.
Is there a reason why writeClose gets called, and how do I prevent this from occurring again whilst debugging?
System details:
Linux Ubuntu 18.04.2 LTS (in WSL)
PHP Version: 7.0.33
Server API: FPM/FastCGI
xdebug version: 2.8.1
If you require any additional information, then please leave a comment, and I shall update accordingly :-)
writeClose is called when you get an exception.
There is no way to prevent it.
The solution is to find where is the exception by debugging deeply.
When you debug then try to use F7 more instead of pressing F8 , you will go through all functionalities and get where the exception is. Then you see the root cause by exception messages.
I've got a CakePHP 1.2-based web site (I know.. too ancient) that I need to upgrade only to whatever is the oldest Cake to support PHP 7.1 (I think roughly Cake 2.8, from what I've seen so far), because my host is upgrading PHP to 7.1 across the board. This site only needs to live maybe 1 more year before we totally replace it, but we don't have time to do that before the host upgrades PHP at end of year.
I am trying to get the web site as-is running in a vagrant VM, so I can go through the upgrade steps there, carefully, and understand exactly what I need to do. My problem now is that I can't get the site to display. More concretely, when I try to load the site with nginx in vagrant, I get nothing but a blank screen with a few PHP warnings (strict standards to the effect of Non-static method Configure::read() should not be called statically), but nothing obviously broken. There's basically nothing in the PHP log, and nothing in the Nginx log. Again, this is the site as currently running (successfully) in production, which means my vagrant PHP is 5.6.38 (the actual production PHP is 5.6.25). Running with php-fpm.
Cake's own logs are only reporting the following, which arises inside a controller method function disableCache(), which is trying to insert headers to prevent the browser from caching the request:
2018-10-22 15:18:57 Warning: Warning (2): Cannot modify header information - headers already sent by (output started at /usr/share/nginx/html/www.mydomain.com/cake/libs/object.php:63) in [CORE/cake/libs/controller/controller.php, line 844]
I have inserted an early return in that method just to stop these warnings.
In PHP, I've got these settings:
error_reporting(E_ALL^E_DEPRECATED);
ini_set('display_errors', 1);
ini_set('error_log', '/var/log/php_errors.log');
In Cake 1.2's app/config/core.php, I've got:
Configure::write('debug', 3);
Database is local MySQL in vagrant, with settings in app/config/database.yml.
Can someone suggest where I should go next in debugging this?
From my own experience, PHP 7.1 and CakePHP 1.2 can work together. You simply need to upgrade your source code to make it compatible with PHP 7.1 but you can continue to have your system in CakePHP 1.2 without having to upgrade CakePHP. Of course, if you can use a newer or the latest version of CakePHP that would be perfect but think of it as a separate project and not something you must do now only because your host is upgrading PHP to 7.1 across the board.
If you can get your Cake project upgraded to 1.3.21 (the last 1.x release), you may be able to use this: https://github.com/littleant/cakephp-1.3.21 instead of upgrading to Cake 2.x. Might buy you a little time!
Zend Eclipse for PHP Developers Version: 3.2.0
php5.4.12 (wamp)
I'm using php eclipse xdebug for a few years now - sometime the xdebug doesn't break.
I notice that it happen mostly on ajax calls, and I found that one cause is that the previous debug session didn't end.
But now I'm debugging an ajax call,
I'm using the chrome devtool and I do 'replay XHR' to run the exact same ajax call, and it doesn't break 2 out of every 3 runs.
This is a great waste of time for me and I would appreciate any idea of how to overcome it, including a suggestion for a different (and better debugger)
Note:
upgrading the php is not an option because I must use the same version as the production sev.
I also tried upgrading the eclipse - but it causes to many (other) issues
In eclipse->preferences->PHP->Debug->Installed debuggers
choose Xdegbug, and click configure
check the Use Multisession checkbox
click ok
This will cause xdebug to break even when a session is already running - but it can be a pain when submiting multiple requests.