This works fine in XDebug 2.1.3 and XDebug 2.2.0 RC1. It breaks in 2.2.0 RC2 and 2.2.0.

Hi! It would be really helpful if you could provide a remote debugging log as well. Please look at http://xdebug.org/docs/all_settings#remote_log on how to make one.

I have one, but I'm concerned about posting this file for all to see.

Do you want it fixed or not?

The file may contain sensitive information (it's hard to tell, it's big.) Are you saying the only way I can get this fixed is if I risk compromising my companies security? Isn't there a more secure way that I can get you the file?

Considering you already uploaded the file containing the data in your test3.zip file, that point makes little sense.

That file does not contain the values of variables, my log does.

I have uploaded an xdebug.log file for you to look at. This is me coming in, landing on the breakpoint, trying to copy the value as well as "Click to see the full value" operation; then finally resuming the program.

This is within PhpStorm 4.0.2 build 117.501.

Let me know if I can provide any other information. This is a really pain in the neck bug as I'm trying to inspect huge JSON strings.

PS: @laurin1 if you would have truncated your log and then ran a simple test for this issue, you would have seen the log entries contain base64 encoded data. You could have worked with the xdebug team to see what this contains. From the looks of it, it contains $_SERVER and $_GLOBAL variables.

Fortunately I'm not as concerned about the details of my local PHP/Apache as it is strictly development and I'm behind a secure network. :)

@awellis13 - I would be happy to send it to them, but I just wasn't comfortable with posting it where everyone can see it. We've had a serious information leak occur in the past, by posting a log that way. Surely, they could provide some means to send data in a secure fashion. I did look through the log and it could contain some sensitive, non-encoded data, depending on the variables grabbed (and again, the log is huge, and I don't have time to comb through every piece of to be 100% certain.) It might not be a risk for you, but it is for me.

Sorry if I sounded snarky... Was having a stressful day and this bug wasn't helping :(

In the future though, if a bug like this happens your best bet is to setup a test script that does not contain sensitive information and reproduce the steps that way. That is what I did, I just took a simple three line script and JSON encoded a massive array containing random crap. :)

I understand about stressful days. :)

Anyway, the problem is that we have passwords in server environment variables. I would literally have to configure another machine to do that, and I suppose I could, but we work with PHPStorm a great deal and their bug tracking system has the ability to upload files with "developer only" security. I'm swamped and having to spend so much time assisting in the debugging of someone else's software, albeit one that I use A LOT and LOVE, is hard to find time for.

You can mail it to me but please make sure the script and log that you mail match and I can run the script without any external resources or libraries

Done.

Related issues from the PhpStorm issue tracker:

http://youtrack.jetbrains.com/issue/WI-11408
http://youtrack.jetbrains.com/issue/WI-11497

@Dearick
I've attached the code fragment and Xdebug logs with various PHP/Xdebug versions (see issue_846_Nikolai.Matveev.zip). The script is very simple:

<?php
$var = print_r(get_defined_functions(), true);
echo $var; //breakpoint here

Please look at the issue, because it prevents some users from using PHP 5.4 (because of unstable version of Xdebug)

Your command is:

property_value -i 12 -d 0 -c 0 -n $var -p 0 -m 0

-m is for the maximum value to return, and you specific 0 so it will return 0 bytes of the large value: ie, nothing. It's possible that this has changed from previously, but "0" does not mean unlimited (say the docs): http://xdebug.org/docs-dbgp.php#property-get-property-set-property-value

I'll add a test case for property_value though, as we don't have one yet.