View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000556||Xdebug||Usage problems (Wrong Results)||public||2010-04-03 18:37||2011-09-25 22:32|
|Target Version||Fixed in Version|
|Summary||0000556: An internal error occurred during: "child count update".|
|Description||I'm seeing the same issues as described in|
(Apparently, I can't reopen that issue.)
At the time you wrote it was a PDT issue. However
claims the opposite, including some interesting analysis.
I'm using php_xdebug-2.1.0beta3-5.2-vc6.dll, which shows as "Xdebug v2.1.0rc1-dev" in phpInfo(). Running on 64-bit Win7 using XAMPP 1.7.1.
The symptoms are the same as in the old issue:
When hitting the first breakpoint, I get
An internal error occurred during: "child count update".
After that I can continue running, but the Variables window remains empty.
|Tags||No tags attached.|
I just tried the latest version in http://xdebug.org/files/xdebug-latest.tgz, php_xdebug-2.1dev-5.2-vc6.dll dated April 1, with the same result.
(beta1 and beta2 used to crash Apache.)
||It is still a bug in PDT. The analysis is incorrect, and Xdebug is *not* required to send anything as base64 encoded. I explained that at http://bugs.xdebug.org/view.php?id=518#c1396|
Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=285371#c14:
Dave Kelsey writes:
"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."
Dave Kelsey keeps claiming that the non-encoded CLASSNAME property is debug code that will go away when Xdebug 2.1.0 gets closer to release. If I understand you correctly, the non-encoded CLASSNAME property is here to stay and any PDT that can't handle it will not work with the current and future RCs and releases of Xdebug.
Since pre-2.1.0 versions of Xdebug don't run on 64-bit Win7, we're in a pretty uncomfortable position here...
Can you clarify, please?
(Please allow me to continue to use this issue for playing the go-between, otherwise things will become confusing...)
It's not debug code, and it has not been removed. It will stay into the next release. When Komodo (http://bugs.activestate.com/show_bug.cgi?id=86445) and netbeans (http://bugs.xdebug.org/view.php?id=556) have added it, I might remove this CLASSNAME pseudo property.
This is unrelated to the PDT crash though. Not handling a non-encoded property is a bug in PDT. Even though Xdebug always has done it, doesn't mean it is *required*. It is not, and other DBGP engines might do it or not as well. The protocol at http://xdebug.org/docs-dbgp.php#properties-variables-and-values states:
encoding - if this is binary data, it should be base64 encoded with this attribute set
It is not binary data, so the data is not required to be encoded in base64. All base64 encoded data, *should* have encoding="base64" as XML element attribute.
||Oops, the netbeans bug is at https://netbeans.org/bugzilla/show_bug.cgi?id=183885|
After some further discussion with Dave Kelsey I gather that he has committed a fix to properly handle the absence of the encoding attribute, but it is unclear (and out of his control) when simple users like me will be able to get a package that includes that fix.
AFAICS, that means I'm locked out of 2.1.0 and PHP 5.3 for the foreseeable future.
Would you consider, as a temporary measure, adding a setting to disable the CLASSNAME pseudo property, so that 2.1.0 could be made to work with current PDT versions that don't have the fix yet?
||This is for netbeans addressed in https://netbeans.org/bugzilla/show_bug.cgi?id=177039|
||The CLASSNAME has been removed in Xdebug 2.1.1. Komodo and netbeans now show the class' type as well, so closing this issue.|
|2010-04-03 18:37||salvis||New Issue|
|2010-04-03 18:37||salvis||PHP Version||=> 5.2.9|
|2010-04-03 18:37||salvis||Xdebug Version||=> 2.1.0-dev|
|2010-04-03 19:00||salvis||Note Added: 0001427|
|2010-04-03 23:31||derick||Note Added: 0001428|
|2010-04-03 23:31||derick||Relationship added||duplicate of 0000518|
|2010-04-03 23:31||derick||Duplicate ID||0 => 518|
|2010-04-03 23:31||derick||Status||new => resolved|
|2010-04-03 23:31||derick||Resolution||open => no change required|
|2010-04-03 23:31||derick||Assigned To||=> derick|
|2010-04-11 15:35||salvis||Note Added: 0001439|
|2010-04-11 15:35||salvis||Status||resolved => feedback|
|2010-04-11 15:35||salvis||Resolution||no change required => reopened|
|2010-04-11 15:39||salvis||Note Edited: 0001439|
|2010-04-12 10:39||derick||Relationship added||has duplicate 0000560|
|2010-04-12 11:18||derick||Note Added: 0001441|
|2010-04-13 19:45||derick||Note Added: 0001448|
|2010-04-21 16:08||salvis||Note Added: 0001455|
|2010-07-23 23:56||derick||Note Added: 0001546|
|2011-09-25 22:32||derick||Note Added: 0001813|
|2011-09-25 22:32||derick||Status||feedback => resolved|
|2011-09-25 22:32||derick||Resolution||reopened => fixed|
|2016-07-31 12:36||derick||Category||Usage problems => Usage problems (Crashes)|
|2016-07-31 12:38||derick||Category||Usage problems (Crashes) => Usage problems (Wrong Results)|