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.

Derick

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.