Community
Participate
Working Groups
Build Identifier: Simply by switching between eclipse-php-helios-M7 and eclipse-php-galileo-SR2 with the same workspace I can see that xdebug works with galileo but not with helios. A wireshark dump shows that xdebug and eclipse do connect and talk to each other, but then eclipse closes the connection. See http://pastebin.com/WfrieQ50 Reproducible: Always Steps to Reproduce: 1. Install xdebug. Version doesn't matter -- reproduced with 2.0.5 and trunk (May 14) 2. Install and run eclipse-php-galileo-SR2 3. Observe that xdebug works correctly 4. Install and run eclipse-php-helios-M7 5. Observe that pdt gets stuck while waiting for XDebug session
Build id: 20100506-2000
I have got the same issue in PDT 2.2 final.
I have got also the same issue in PDT 2.2 final. (64bit machine, xdebug 2.0.5)
Same situation in here. Yesterday I've downloaded Eclipse Helios PHP version and it was fine until I needed to debug something. I've checked configuration twice and it was all exactly like in previous Galileo version which worked fine for me. Luckily I saved previous eclipse. So for now I needed to switch back. IMHO this bug is major for any PHP developer.
I have the same problem with vista. I have stayed with Apache 2.2 but went leading edge installing: eclipse-php-helios-win32 + PHP 3.6 + php_xdebug-2.1.0RC1-5.3-vc6.dll + Firefox 3.6.4 yes. I noticed that the zend_extension_ts is now zend_extension and I can see php -m display xdebug. Everything seems to work OK except debug. My previous europa installation worked ok including debug - which I'll have to restore.
(In reply to comment #5) > I have the same problem with vista. > I have stayed with Apache 2.2 but went leading edge installing: > eclipse-php-helios-win32 + PHP 3.6 + php_xdebug-2.1.0RC1-5.3-vc6.dll + Firefox > 3.6.4 > yes. I noticed that the zend_extension_ts is now zend_extension and I can see > php -m display xdebug. > Everything seems to work OK except debug. > My previous europa installation worked ok including debug - which I'll have to > restore. Please ignore my submission above. I restored my previous version of everything. Then got it to work with PHP 5.3.2. Then went forward again to Eclipse 3.6 and that now works too! Sorry about this everyone.
Can everyone please do the following to provide more information 1. Start with a clean workspace 2. collect an xdebug log demonstrating the problem (see http://www.eclipse.org/pdt/documents/XDebugGuideForPDT2.0.pdf for more information on how to collect an xdebug log) 3. post the xdebug log along with details of operating system, xdebug and php levels. If the problem only shows itself when using an existing workspace then that information would be good to know as well.
(In reply to comment #7) I have created a new workspace and I could debug. But I have not tested all things. I need some time to evaluate the differences between the old workspace and the new one. But how could I convert the old workspace to work with it like the new one?
Created attachment 173121 [details] xdebug log <?php $var = 'test'; // change in debug mode the value: $var = 'test test2'; echo $var;
So potentially the problem is fixed by using a new workspace. One other reason for the problem could be that there were 2 instances of eclipse running or something else listening on port 9000 stopping PDT 2.2 from being able to listen on port 9000. Basically you cannot have 2 versions of PDT running at the same time configured to use the same xdebug port. I don't know of any easy way to recreate your workspace from PDT 2.1 to PDT 2.2 but I am hoping that isn't the case as I cannot recreate this issue when I swap between 2.1 and 2.2 using the same workspace. You may want to try for example deleting and recreating the launchers. But I think it may be that something else was listening on port 9000 not PDT 2.2. Are there any entries in the PDT error log at all ?
Hello Dave, I believe your theory that port 9000 is blocked by another application is not true. For Example I did the following Steps: In [Preferences] -> [PHP] -> [Debug] -> [Installed Debuggers] -> [XDebug] -> [Configure] I set [Accept remote session (JIT)] to [prompt] (any should work either). This way PDT is able to receive the debug session signals again. But still this doesn't solve the problem and is just to demonstrate that communication technically is possible, but ignored by PDT in the usual case. Can you provide more information how to delete and recreate the launchers? Nils
click the down arrow next to the debug icon and select "Debug Configurations" select your launcher and then click on the big red cross icon to delete. What I really need to see is an xdebug log from someone with a failing scenario, plus the eclipse PDT 2.2 error log entries as well. Also Nils, can you confirm that you can get it working with a clean workspace ? I am unable to recreate this problem, so we still need to determine what the differing factors are.
Created attachment 173388 [details] xdebug log : could not debug This xdebug.log shows the same constellation, but in eclipse it doesn't start the debug mode. In 'PHP Debug'-mode I couldn't stop at a breakpoint ... I have no effect with deleting the launchers.
In the second log you have posted, xdebug is doing something unexpected, after issuing the stderr command I get the expected response, but then the script is just executed and it terminates. xdebug did not wait for any further commands which it should do, so I don't know what is wrong here but certainly xdebug is not behaving correctly and PDT is not able to do anything. So either there is a bug in xdebug or xdebug is not setup correctly on your system, but in the previous log you posted xdebug behaved as expected. I see xdebug 2.1 has been released, maybe you could try that ?
(In reply to comment #14) It isn't a bug in xdebug, because - if I use the old workspace it doesn't work - if I use a new workspace it works I have used at each test case the same xdebug (2.0.5) and the same php version Or I have made something wrong with my 2 test cases ... Should I use a specified version of PHP? >= 5.2 or >= 5.3
Is there anything in the PDT error log ? The file can be found in the .metadata directory in you workspace, the file is .log
One other thing to try, in the old workspace, remove all your breakpoints (ie no entries at all in the Breakpoints Tab view). Then load the workspace into PDT 2.2 and see if you can now work with the old workspace.
(In reply to comment #17) The solution for me was to remove all breakpoints. (No reload needed, ...) Thanks
Was there anything in your PDT error log ? That would be really handy for me to know as it may contain info as to why you had a problem with breakpoints.
(In reply to comment #19) Sorry, I've nothing found in .../.metadata/.log that could be written by debugging. I have instead sometimes an other error: (I should search the bug number for this. ;-) . Perhaps this is NOT the reason of the bug. ) !ENTRY org.eclipse.core.jobs 4 2 2010-07-01 13:03:59.571 !MESSAGE An internal error occurred during: "Processing Dirty Regions". !STACK 0 java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$ValueIterator.next(HashMap.java:822) at org.eclipse.dltk.internal.core.index.sql.h2.H2Cache.searchElements(H2Cache.java:293) at org.eclipse.dltk.internal.core.index.sql.h2.H2ElementDao.search(H2ElementDao.java:194) at org.eclipse.dltk.internal.core.index.sql.SqlSearchEngine.search(SqlSearchEngine.java:146) at org.eclipse.dltk.core.index2.search.ModelAccess.findElements(ModelAccess.java:285) at org.eclipse.dltk.core.index2.search.ModelAccess.findElements(ModelAccess.java:263) at org.eclipse.php.internal.core.model.PhpModelAccess.findIncludes(PhpModelAccess.java:110) at org.eclipse.php.internal.core.filenetwork.FileNetworkUtility.internalBuildReferencedFilesTree(FileNetworkUtility.java:261) at org.eclipse.php.internal.core.filenetwork.FileNetworkUtility.buildReferencedFilesTree(FileNetworkUtility.java:246) at org.eclipse.php.internal.core.filenetwork.FileNetworkUtility.buildReferencedFilesTree(FileNetworkUtility.java:221) at org.eclipse.php.internal.core.typeinference.PHPModelUtils.fileNetworkFilter(PHPModelUtils.java:185) at org.eclipse.php.internal.core.typeinference.PHPModelUtils.fileNetworkFilter(PHPModelUtils.java:154) at org.eclipse.php.internal.core.typeinference.PHPModelUtils.filterElements(PHPModelUtils.java:243) at org.eclipse.php.internal.core.typeinference.PHPModelUtils.getFunctions(PHPModelUtils.java:610) at org.eclipse.php.internal.ui.editor.highlighters.DeprecatedHighlighting$DeprecatedApply.visit(DeprecatedHighlighting.java:89) at org.eclipse.php.internal.core.ast.nodes.FunctionInvocation.accept0(FunctionInvocation.java:78) ....
you are right it doesn't look relevant. Many thanks for your help in debugging this and at least we have a workaround for you.
It looks like when the breakpoint manager attempts to reload the persisted breakpoints from a PDT 2.1 workspace inside of PDT 2.2, the filename results in null through the following code String fileName = (String) marker .getAttribute(StructuredResourceMarkerAnnotationModel.SECONDARY_ID_KEY); if (fileName == null) { fileName = (String) marker.getAttribute(IMarker.LOCATION); } in PHPLineBreakpoint.java(createRuntimeBreakpoint) so when xdebug attempts to create the breakpoint it needs, and tries to set the filename it fails because setFileName attempts to compare to the existing filename which is null and it fails. Because Xdebug sets the filename into the breakpoint it would be easy to change the setFilename code to check to see if the existing filename is null and just let the setfilename override it. But the real cause of the problem is the above code where fileName is set to null then stored in the internal breakpoint.
So there appears to have been some issue with some of the framework code used by PDT 2.1 such that breakpoints were not persisted correctly. They did not contain the location attribute of a marker. When they are reloaded in, PDT sets the breakpoint filename to null and when the xdebug logic tries to override this, the PDT logic attempts to compare the new entry with one that is set to null and a nullpointerexception occurs. This probably explains why people were having situations where breakpoints were working at one point and not the next in PDT 2.1. The persisted info is not correct and so the solution is to allow xdebug to set the filename without causing a null pointer exception. This means either guarding against a filename being set to null, or checking for null when attempting to set the filename.
I have put a fix in now that will stop xdebug from causing a NPE when trying to set the filename. This means it will set the filename and provide the breakpoint now with a valid filename (missing from the persisted information) and should allow PDT 2.2 to use PDT 2.1 workspaces without having to delete the breakpoints
Assuming closed. Will be reopened if needed by the community
