Community
Participate
Working Groups
When using XDebug in conjunction with eclipse PDT and stepping through, the following error might be thrown. The error is thrown when the variables view is displayed. The variables view is blank. An internal error occurred during: "child count update". Exception Stack-Trace: java.lang.NullPointerException at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpStringValue.<init>(DBGpStringValue.java:39) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpVariable.parseProperty(DBGpVariable.java:75) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpVariable.<init>(DBGpVariable.java:44) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpContainerValue.parseData(DBGpContainerValue.java:97) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpContainerValue.<init>(DBGpContainerValue.java:37) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpVariable.parseProperty(DBGpVariable.java:83) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpVariable.<init>(DBGpVariable.java:44) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpTarget.parseVarResp(DBGpTarget.java:1210) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpTarget.getContextLocalVars(DBGpTarget.java:1123) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpTarget.getContextAtLevel(DBGpTarget.java:1177) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpTarget.getVariables(DBGpTarget.java:1158) at org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpStackFrame.getVariables(DBGpStackFrame.java:148) at org.eclipse.debug.internal.ui.model.elements.StackFrameContentProvider.getAllChildren(StackFrameContentProvider.java:51) at org.eclipse.debug.internal.ui.model.elements.StackFrameContentProvider.getChildCount(StackFrameContentProvider.java:28) at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.retrieveChildCount(ElementContentProvider.java:114) at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$2.run(ElementContentProvider.java:63) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Hi, can you give some more detail for me. What version of xdebug are you using ? and the version of php ? Also I am sorry I don't recognise version 2.2 what version of eclipse and PDT are you using ? Finally, do you know what strings variables you were trying to display and the content you expected ? I would like to try to recreate the problem if I can. Many thanks
Thanks for the quick response. Here are some more information: Eclipse SDK Version: 3.5.0 Build id: I20090611-1540 I am using PHP 5.3 Thread-Safe (and tried also non-thread-safe), XDebug 2.0.5 (and tried also XDebug 2.1-dev) and PDT 2.1[.1] (tried also PDT 2.0 and PDT 2.2 (Nightly Build) every combination results in the same error. To reproduce the problem I created a test.php with the following content: <?php class MyClass { private $myArray; public function __construct() { $this->myArray = array (1,4,2,23); } public function getMyArray() { return $this->myArray; } } $classInstance = new MyClass(); $BREAKPOINT_HERE = $classInstance->getMyArray(); ?> Put a breakpoint at line 15. I am using "Debug As..." -> "PHP Web Page". The Webserver is IIS 7. If you need more details please let me know.
I tried to reproduce the problem using the script you provided, but couldn't from a php command line. My guess is that it might have something to do with the superglobals. Could you get an xdebug trace for me. To do that add the line xdebug.remote_log="c:\xdebug.log" or something similar to create the log and could you attach it to the bugzilla. Also you could try turning off superglobals in the xdebug preferences and see if the problem goes away. Thanks
Created attachment 143269 [details] effective XDebug-settings viewed with phpinfo()
Created attachment 143270 [details] xdebug.log
I added xdebug.dump_globals = Off to the XDebug settings section and got the same error. attached is a screenshot with my effective XDebug settings and the xdebug.log you asked for.
Created attachment 143278 [details] Screenhot showing eclipse php-debug view and the error-message After the error-message is shown no variables are displayed in the tab anymore until eclipse is restarted.
Thanks for the xdebug.log, I have found the cause. It seems that in the xdebug version listed as 2.1-dev, there appears to be some temporary code which creates a non existant variable called CLASSNAME. The data is a string but not base64 encoded and PDT doesn't know how to handle a string from xdebug that is not base64 encoded as xdebug should never send a string variable in any other format except base64 encoded. The fix is to use a version of xdebug that is marked as 2.0.5 or earlier. However when I downloaded what I thought was a 2.0.5 version I actually got a 2.1-dev version so you need to check I would expect the temporary code to be removed for official releases of xdebug so there should be no impact to PDT, but it is probably worth putting a fix in to better handle the above scenario. To determine the version of xdebug, do "php -v" and confirm you have a 2.0.5 or earlier version. That should solve the problem.
Thanks for your excellent feedback and quick replies. I couldn't get the 2.0.5 version from xdebug.org running (php crashed immediately) but found 2.0.6-dev version that worked and fixed the issue. Again many thanks for your quick skilled analysis.
*** Bug 286712 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > found 2.0.6-dev > version that worked and fixed the issue. Hello Frank, I've the same issue on Eclipse 3.4.1 PDT 2.0 (Win Vista). I've looked for 2.0.6 version but I'ven't found it.. So where can I find it (dll vc6)? Thanks a lot. Bye.
Marked as Resolved by the Reporter (see Comment #9) Closing the issue - please reopen if still relevant. [Sylvia Tancheva]
(In reply to comment #8) > Thanks for the xdebug.log, I have found the cause. It seems that in the xdebug > version listed as 2.1-dev, there appears to be some temporary code which > creates a non existant variable called CLASSNAME. The data is a string but not > base64 encoded and PDT doesn't know how to handle a string from xdebug that is > not base64 encoded as xdebug should never send a string variable in any other > format except base64 encoded. According to Derick Rethans, your analysis is not correct, and the bug is in PDT after all. See http://bugs.xdebug.org/view.php?id=518#c1396 : Eclipse PDT does *not* handle this correctly. Values are only base64 encoded if that attribute is present, and as you can see from the XML above, the encoding="base64" attribute is not available for the extra CLASSNAME property. This is something that needs to be fixed in PDT, as it is described in the specs: http://xdebug.org/docs-dbgp.php#properties-variables-and-values (last element in the table). [How can I reopen this issue?]
so first off, the reason this fails on that particular release of xdebug BETA code was due to some debug code left in by Derick which has now been removed. So the issue only occurs with that particular release of xdebug BETA code. Maybe future versions will send non encoded string data in the future, but all the official releases so far have not done so. However a fix in PDT was put in a while ago for this. I have no idea if any official builds of PDT contain this fix or not. So you may be able to get a version with a fix in or you may not, I don't know. Alternatively move to an official release of xdebug. You don't need to re-open this issue
Dave Kelsey wrote: > so first off, the reason this fails on that particular release of xdebug BETA > code was due to some debug code left in by Derick which has now been removed. > So the issue only occurs with that particular release of xdebug BETA code. You keep repeating this, but it's not true. You seem to refer to Xdebug 2.0.6, but we're talking about Xdebug 2.1.0. At http://bugs.xdebug.org/view.php?id=556#c1441 Derick Rethans clearly writes "It's not debug code, and it has not been removed. It will stay into the next release." > Maybe future versions will send non encoded string data in the future, but all > the official releases so far have not done so. It's not "maybe" -- it's for sure. Since Xdebug 2.1.0 is the first version to run on 64-bit Win7, any PDT that is unable to handle non-encoded string data and thus fails with Xdebug 2.1.0 is not viable on 64-bit Win7. Not following the specifications (as Derick goes on to explain) is a very serious PDT bug and you are wrong in down-playing it.
being rude and aggressive really is not the way to expect help. I don't agree with your interpretation either.I have said this is fixed. There is nothing more to discuss.
I'm sorry I came across as "rude and aggressive". I didn't mean it that way, I'm just trying to bring together the different truths that are propagated on bugs.eclipse.org and bugs.xdebug.org. I'm also a bit frustrated about not having any timeframe (or at least a version number) for expecting a fix: > I have no idea if any > official builds of PDT contain this fix or not. So you may be able to get a > version with a fix in or you may not, I don't know. Not being able to debug PHP 5.3 code, at first because of Xdebug crashes and now because PDT doesn't run with Xdebug 2.1.0alpha/beta/rc (and both parties putting the blame on the other), has plagued me for half a year now and there's no end in sight! Xdebug has its own share of problems when running under 32-bit WAMP on 64-bit Windows, and testing Xdebug 2.1.0rc is on the critical path. Not being able to do that because PDT can't handle it crushes all hopes for getting this to run in the foreseeable future, and PDT denying being part of the problem really doesn't help either. > Alternatively move to an official release of xdebug. You put it as if it were my fault for not implementing the easy solution and I was just being obnoxious. AFAICS no such easy solution exists for 32-bit WAMP on 64-bit Windows, because only Xdebug 2.1.0 runs with PHP 5.3 on that configuration. Thank you for your work on PDT and for putting up with nagging users like me. I put a fair amount of my spare time into the Drupal open source project and that work depends on PDT/Xdebug. I hope your fix will eventually trickle down, thanks.
If you stumble upon this bug report, but you are using the latest version of PDT and Xdebug, there is a possible solution: delete all your breakpoints in PDT and re-create them. Deleting & re-creating breakpoints fixed the issue for me and I was then able to break at any point, as well as see my 'variables' pane.
