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.
Related
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.
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
I'm weaning myself off of PhpStorm for the inevitable day my student license expires. I'm trying to set up PDT (comments regarding other free PHP environment suggestions are appreciated, but do not answer the question).
Anyways, when I add a PHP executable, there is a mandatory option for a debugger. Leaving the default at Zend, when attempting to run a hello world file with the big green button I get a
"Launch Error - Session Terminated"
"Error launching testFile The session could not be started.
In order to generate debug information, please make sure that the debugger is properly configured as a php.ini directive."
The question is basically - is this error generated because I haven't set up a debugger? But it follows, if so, to ask if it is possible to use PDT without a debugger. If it is not possible, why? You don't need a debugger for PhpStorm. Is it simply a matter of Eclipse not supporting this use case, or is there a gap of my understanding of the toolchain and is PhpStorm doing something significant to make itself work without a debugger?
And I guess, is there any reason to actually want to not install a debugger besides (the probably negligible) overhead to actually setting it up?
Of course you can use PDT without a debugger. Due to this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=462020, you have to configure executable with xdebug.
You can also create official bug on bugs.eclipse.org to add "none" in php cli configuration.
EDIT:
In PDT 3.5 (Eclipse 4.5 - Mars release), we added "NONE" as possible choice. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=467260
I have an application I'm working on in which I make many AJAX calls to external PHP files. These PHP files get certain parameters, connect to the DB, and perform a task with them.
I just recently started using Netbeans for an IDE and love it thus far. However, whenever I put a breakpoint on one of my external PHP files (the ones I'm making AJAX requests to) and attempt to run the debugger, my breakpoints are never hit. Am I doing something wrong? Or does the Netbeans debugger not stop on the breakpoints of external files you are referencing?
NetBeans need to be configured to use xdebug, before you can strt debugging. For instructions on installing and configuring xdebug see here: http://wiki.netbeans.org/HowToConfigureXDebug
Here is a nice step-by-step tutorial for setting this up. A little less wordy than the netbeans documentation:
http://arturito.net/2011/05/21/local-and-remote-php-debuging-in-netbeans-with-xdebug-on-google-chrome-just-like-in-visual-studio/
My Xdebug works fine when I use eclipses' internal browser but when I use it in an external browser apache crashes.
I am using xampp and on windows 7 64 bit. If someone needs more information let me know.
For some reason if I have the variables tab open in the php debugger in eclipse it crashes apache. So to stop it I just can't have variables tab open while debugging. So this avoids the problem but doesn't fix it. I would like to be able to have this tab. Any suggestions?
It is possible that the XDebug build and type does not match your apache & php build and type...
Apache compiled with VS.NET 2008 (VC9) for 32bit and using PHP as a module would require XDebug: 32bit, VC9, Thread Safe.
http://xdebug.org/download.php
Also, you could test another WAMP package that comes with XDebug (for example WampDeveloper) and if it also does not work for you, it's probably not a build mismatch issue.
Hey I got this working
Eclipse 3.6.1 (because on later versions key shortcut for putting line comment don't work)
Xampp 1.7.4
Xdebug 2.1.2
The trick is to change php from VC6 to VC9 and then it just works correctly.
BTW. It's the variables panel that causes xdebug to crash apache on php VC6.
Remember to get VC9 version of xdebug for new php AND if you put your new php in directory other than
\xampp\php, then on phpinfo(); you'll see that there's no php.ini loaded so just rename old php (co you can swich them from one to other anytime) and put new php in the same directory in which original php was in "\xampp\php" and copy your php.ini (because paths doesn't change). Also remember to obtain any additional php extensions you've been using in VC9 version for new php and put them in "\xampp\php\ext"
I can confirm most of what t0meck said. Except I've moved up to xampp-win32-1.7.7-VC9 which has PHP 5.38. Taking the phpinfo() results from that to Xdebug's custom installation analyzer, it specifies the php_xdebug-2.1.2-5.3-vc9.dll, but the problem isn't entirely eliminated. As I've documented in my 'notes to self' page, the following is working for me.
After following the above procedure, the 'run as' should work on the first try, but the 'debug as' may crash Apache at every attempt. This is an issue that has driven many people to severe distraction. There is an apparent bug exposed using the debug perspective. At the top center of the perspective is a window with two tabs, the variable view and the breakpoint view. Usually, Apache crashes only when the variable view is highlighted, so highlight the breakpoint view instead. Then set a breakpoint on your project. Now, if you are one of the chosen, you will be able to step through the script using the debugger, but when you switch to the variable view it may still crash Apache. What a drag. Repeat the process and the next time you should actually see the variables and the problem will magically go away, until you restart the project. Just repeat the procedure and be satisfied with being one of the lucky ones.
Don't know if this help, I have same kind of issue, but it relate to array depth xdebug >handle in Variables view. And you can change it. Widnow > Preferences > PHP > Debug > >Installed Debug > Xdebug > Configure enlarge the "Max array depth" solved my issue.
http://bugs.xdebug.org/view.php?id=658#c1767
Just set it to 10 or bigger and it should work