Xdebug stopped working in PhpStorm. The connection is lost in less than a second. I connect to Xdebug via SSH. I have attached a video with the bug. I will be grateful for any help.
PHP 7.3.33
Xdebug 3.1.5
PhpStorm 2022.2.3
Mac OS
bug video (google disk)
General approach in troubleshooting here:
Enable Xdebug log (most likely will need to restart your web server/php-fpm) and try to debug again. Then check the log to see if it was a clean exit or it just died/process terminated. Maybe Xdebug is crashing.
You may also enable extra logging on PhpStorm end to see their side of things. Then you can check the idea.log via PhpStorm | Help | Show Log in XXX
P.S. Just in case: see if disabling Settings (Preferences on macOS) | PHP | Debug | Enable '__toString' object view option will make any difference. PhpStorm 2022.2 has implemented this functionality but it looks like not all corner cases may be covered yet.
Since disabling the Enable '__toString' object view option helped, then please check out the 2022.3 EAP version -- EAP builds have a few tickets fixed in this area.
Since it works OK for you in 2022.3 EAP build then it could be one of these tickets (cannot say which one without knowing the code / seeing the logs etc.):
WI-68096 -- '__toString' in Debugger triggers custom error handler
WI-68622 -- Enable '__toString() object view': code that reads from stream ends early under debugger
Related
Xdebug is not working despite phpinfo() is showing Xdebug section and in VS Code the red point is displayed and the control panel. Also the debug console is started as well.
I've tried to reinstall it again. I removed Apache and install XAMPP and then install Xdebug there.
There is currently an issue with Xdebug 3.2 on Windows (specifically Apache) where it enables all features even when not requested. It is possible that this also affects other functionality like breakpoints. Until this is fixed, I recommend to use Xdebug 3.1.6, which you can still find on the historical downloads page.
However, if you use xdebug_info() instead of phpinfo(), Xdebug will tell you what it tried to do (if anything at all) to connect to the debug client. There might be hints in there too.
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 can't seem to use xdebug in PHPStorm when running a local server. The server document root is the direct parent of the PHPStorm project root and I can run the project on a web browser and through the "Tools | Test RESTful Web Server" option.
I:
am running my Apache server on a mac (OSX 10.10.5) and used brew to install php 5.5 and xdebug 2.3.3 (which was honestly a huge hassle, as nothing wanted to work). The xdebug shows up properly in my phpinfo() and when I use the terminal command $ php -i so I think it is installed correctly.
have followed several guides, tutorials, and SO questions that either do not pertain to my situation and/or their answers were non-working or absent
Configuring Xdebug (PHPStorm) and may more from the PHPStorm website...
Connection Between PHP and Xdebug (SO) this one was the closest I could find to my situation and it did not resolve my issue either. All the other ones I could find were not very helpful because they were working with the MAMP stack.
can't validate my xdebug with PHPStorm in "Run | Web Server Debug Validation". Everytime I try, no matter how I fiddle with the settings, it is either a connection refused error (which I believe is because I am trying unopened ports) or this:
Web Server Debug Validation returns unexpected format error.
Both the bookmarklets that XDebugger supplies on their website and the browser extensions fail as well.
The weird thing to me is, if I create a virtual host in the apache httpd.conf with the servername as my external IP address and with the same document root, I can access it (not the weird part) but I can also run the debugger perfectly fine through it. This is undesirable as it seems that anyone can now run my code and receive responses with sensitive information. They might also be able to start my debugger, but that would be more of an annoyance if they could.
I have been able to, up until this point, work without a debugger, but there have been instances where it would have been great to have one. Looking toward the future I can say for certain that having a debugger will help immensely with my projects, so any help would be greatly appreciated.
I would also prefer not to reinstall everything as it was a huge pain to set it all up in the first place, but if it's a last resort I may have to.
I can provide more information if needed.
Thanks,
Jacob
I managed to get the step debugging to work with a couple changes:
For the validation test, instead of just localhost I attempted to validate a sub-folder that contains my code for the project. The PHPStorm project itself was set to this folder. I think that because my document root was outside of the project that it refused to validate the xdebug extension.
I also configured my DBGp Proxy under Tools to accept the IDE key that xdebug had set as default and updated the IDE key in the xdebug bookmarks.
I can now step debug with Run > Start Listening for PHP Debug Connections and in-browser using the XDebug Debugger bookmarks.
Jacob
In addition to the accepted answer, you need to download and run the debug proxy on the server itself
Download an install the Python Remote Debugging package from Komodo (http://code.activestate.com/komodo/remotedebugging/)
Start the DBGp proxy on the web server.
In PHPStorm, start listening for the debugger: "Run | Start Listening for PHP Debug Connections" (You may need to register the debug server: "Tools | DBGp Proxy | Register IDE")
Jet Brains how-to: https://confluence.jetbrains.com/display/PhpStorm/Multi-user+debugging+in+PhpStorm+with+Xdebug+and+DBGp+proxy#Multi-userdebugginginPhpStormwithXdebugandDBGpproxy-2.DBGpproxy
None of the suggestions worked for me, so I kept digging.
Even though IPV6 was disabled on my network adapter, it is still a preference on the loopback adapter.
A ping localhost would result in Reply from ::1: time<1ms
I've fixed this by preferring IPV4 over IPV6 in the Windows registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters
Set DisabledComponents to Hex 0x20 or decimal 32.
Now ping localhost comes back as Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 and the debugger validation works fine.
Linux Mint 15, Aptana Studio 3.4.1, Chromium 28.0.1500.71
Sorry, this is a little lengthy to explain. Please let me know if something's not clear.
The title is my goal. I have a local server set up with Apache2. I don't know if it matters, but I have dnsmasq set up to redirect, for example, site.dev/index.html to /home/wastvedt/Projects/site/www/index.html (described here).
I've followed the tutorials I can find. XDebug is running, I have the helper installed in Chromium, and the debugger, interpreter, and web server set up in Aptana.
I'm working on a WordPress site and want to break on one of the functions in my theme's functions.php file. I created a breakpoint in the function in Aptana, turned on the XDebug helper in Chromium, and updated a post, which calls the function in question. Aptana recognizes what I'm doing and prompts me with the option of breaking on the first line. Regardless of what I select, I see "XDebug JIT Session [Remote Launch]" in the Debug view. The prompt appears three times, but nothing else happens in Aptana.
I think the problem might have something to do with linking files in the editor to files in Apache. When I try this JIT debugging thing with "localhost" (located at /home/wastvedt/apache2/www/index.php), Aptana brings up /home/wastvedt/Projects/site/www/index.php. This isn't right, but maybe the real problem is somewhere else. To be honest I'm a little lost now.
Any thoughts? I'd provide some sort of dump or output, but I'm not sure which or what.
Thanks for reading,
Trygve
In order to properly setup XDebug with Aptana I setup the below options by going to the Window menu -> Preferences -> Aptana Studio -> Editors -> PHP -> Debug:
Allow multiple debug sessions: Always
Break on first line when an unknown remote sessions (JIT): Never
Then click on XDebug in Installed Debuggers -> Configure:
Use Multisession: OFF
Accept remote session (JIT): any
That pretty much made it work for me.
I've been using Eclipse 3.4.2 with PHPEclipse and Zend Debugger for some time without issue. Suddenly, I cannot debug the PHP scripts. I can run them fine but when I select Debug As... the script shows in the Debug window as if it were running, but it is not. If I click pause it reports as being on line 0. I can step through it, if I resume, let it sit and then pause it again it still reports being on line 0.
I've tried closing everything all down, restarting my system, and creating a new project without luck.
I had recently updated the Ubuntu system, but there was nothing related to PHP or Eclipse (that I could tell). XULRunner was updated.
I've checked the Debug Configs, it has the Zend Debugger and the PHP Executable selected as they had been before when working. I've played around with Editing the Source Lookup to make sure it's looking at the right place.
Any ideas?
Edit: eclipse's debugger is listening on port 10000 i can telnet localhost 10000 fine. when i send some garbage characters eclipse pops up an error message about incompatible debugger so it seems to be listening
Edit: I wasn't able to figure out what was really going on but creating a new workspace seemed to do the trick
Update: I tried eclipse -clean (i'm on ubuntu) but that didn't help me. I found the .log file and noticed the following errors. On Startup:
!ENTRY org.eclipse.osgi 2 1 2009-10-05 17:02:11.979
!MESSAGE NLS missing message: DebugConnectionThread_oldDebuggerVersion in: org.eclipse.php.internal.debug.core.PHPDebugCoreMessages
!ENTRY org.eclipse.osgi 2 1 2009-10-05 17:02:11.980
!MESSAGE NLS missing message: DebugServerTestEvent_success in: org.eclipse.php.internal.debug.core.PHPDebugCoreMessages
!ENTRY org.eclipse.osgi 2 1 2009-10-05 17:02:11.980
!MESSAGE NLS missing message: DebugServerTestEvent_timeOutMessage in: org.eclipse.php.internal.debug.core.PHPDebugCoreMessages
After I try to start a debug session:
!ENTRY org.eclipse.php.debug.core 4 10001 2009-10-05 17:02:23.455
!MESSAGE Can't determine version of the PHP executable
!ENTRY org.eclipse.php.debug.core 4 10001 2009-10-05 17:02:23.983
!MESSAGE PHPDebug plugin internal error
!STACK 0
java.lang.NullPointerException
at org.eclipse.php.internal.debug.core.preferences.stepFilters.DebugStepFilterController.isFiltered(DebugStepFilterController.java:98)
at org.eclipse.php.internal.debug.core.zend.debugger.handlers.ReadyNotificationHandler.handle(ReadyNotificationHandler.java:34)
at org.eclipse.php.internal.debug.core.zend.communication.DebugConnectionThread$InputMessageHandler.run(DebugConnectionThread.java:881)
at java.lang.Thread.run(Thread.java:636)
I'm trying to see if I can track down anything else given this.
You mentioned that you couldn't figure out what was going on, but creating a new workspace seemed to solve the problem. The case is probably just a well-known issue with Eclipse. Basically, over time, cruft tends to build up in the system. As this happens, Eclipse (and particularly the plugins) start to break. You can solve this (without creating a new workspace) by using the -clean argument when starting Eclipse.
So, if you are running Windows, edit the shortcut pointing to Eclipse so that you see:
eclipse.exe -clean
That should help. Read more information about it here: Keeping Eclipse Running Clean
One of the really nice things about eclipse is that it has no installer, although I see some well-intentioned traveller on a certain road has made it possible for you to do apt-get eclipse. (Hint: don't do that.)
One of the not-so-nice things is that it is rather complex. If you think you may have flipped one of the thousands of switches it has, just unpack the archive and do a parallel install. Eclipse is well-behaved that way, even on windows. If the parallel install works, then at least you know it's just your workspace or configuration, and if it doesn't, you know to look externally. (Err, unless you made the same mistake twice with your run config.)
Were any changes made to your firewall? I use NuSphere's php debugger, and it communicates via a TCP socket. If your firewall was modified during the update, your firewall could be preventing the debugger server from contacting your debugger client via the localhost port it (maybe) runs on. Not too sure how Eclipse's debugger works, but I would guess the same way.
For kicks, you can try running snort to see if the debugger is sending packets to you.