View Issue Details

IDProjectCategoryView StatusLast Update
0000556XdebugUsage problems (Wrong Results)public2011-09-25 22:32
ReportersalvisAssigned Toderick 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version2.1.0RC1 
Target VersionFixed in Version 
Summary0000556: An internal error occurred during: "child count update".
DescriptionI'm seeing the same issues as described in
http://bugs.xdebug.org/bug_view_page.php?bug_id=458

(Apparently, I can't reopen that issue.)

At the time you wrote it was a PDT issue. However
https://bugs.eclipse.org/bugs/show_bug.cgi?id=285371#c8
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".
java.lang.NullPointerException

After that I can continue running, but the Variables window remains empty.
TagsNo tags attached.
Operating System
PHP Version5.2.9

Relationships

duplicate of 0000518 closedderick make CLASSNAME pseudo-property optional, not necessary. 
has duplicate 0000560 resolvedderick base64 encoding / "child count update" / PDT bug 

Activities

salvis

2010-04-03 19:00

reporter   ~0001427

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.)

derick

2010-04-03 23:31

administrator   ~0001428

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

salvis

2010-04-11 15:35

reporter   ~0001439

Last edited: 2010-04-11 15:39

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...)

derick

2010-04-12 11:18

administrator   ~0001441

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.

Derick

derick

2010-04-13 19:45

administrator   ~0001448

Oops, the netbeans bug is at https://netbeans.org/bugzilla/show_bug.cgi?id=183885

salvis

2010-04-21 16:08

reporter   ~0001455

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?

derick

2010-07-23 23:56

administrator   ~0001546

This is for netbeans addressed in https://netbeans.org/bugzilla/show_bug.cgi?id=177039

derick

2011-09-25 22:32

administrator   ~0001813

The CLASSNAME has been removed in Xdebug 2.1.1. Komodo and netbeans now show the class' type as well, so closing this issue.

Issue History

Date Modified Username Field Change
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)