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.
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
Firstly forgive me if my terminology isn't entirely accurate. I have only limited knowledge on this subject, but will best try to convey the problems we are having. My server administrator is trying to deploy php 5.5.9 on a live server. Originally the intention was to install php 5.4.x, but we opted for the latest version instead (a manual compile is required regardless due to the o/s)
The O/S is OpenSuse 12.1 and the server is a Plesk server (Plesk Version 11.0.9) with Apache 2.2.1. This particular o/s does not have the ability to update php automatically so everything has to be done manually. Since we didn't want to risk screwing up the server (currently running with php 5.3.8), we opted to install a second version of php alongside the current one. The instructions we followed are outlined here: http://kb.parallels.com/en/114753
After numerous failed attempts due to missing libraries during compilation, we were finally able to compile php 5.5.9 without error and then proceeded to run tests with 'make test'
Unfortunately, the test results came back with 32 failures and 20% of the total tests were skipped. A total of 13011 tests were done, 10410 of which were completed. The TEST SUMMARY can be downloaded from here: http://uploaded.net/file/v6ug55l8
Anyway, deciding we might aswell give it a try, we applied the changes as indicated in the first link above to the vhost.conf. However, it didn't work, and the vhost then returned Internal Server Errors for every page regardless of script or extension. The errors logs sadly do not indicate any errors, only a whole ton of internal server errors recorded by mod_security. We did notice a huge number of these in the error log: Warning: SuexecUserGroup directive requires SUEXEC wrapper. But, it doesn't seem to be related, as the same error goes back several weeks.
So, we're stuck without any idea what to do next. Our next attempt will be to try and compile a php 5.4.x instead, as perhaps something is bumping heads with 5.5.9...
Any and all advice will be appreciated. As per the opening statement, I'm not an expert here, so if you need any additional information about the machine and it's server, feel free to ask. Thankyou for your attention!
Problem solved. The vhost's CGI-BIN needed to be CHMOD 755 and not 775.
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
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.