Please follow the instructions at https://xdebug.org/support.php#remote to submit a good debugger issue. I will need that before I can investigate and fix this.

Its hard to make you a small script, because its all in core of yii and yii2 framework (also using DB).

I found that this BUG already was in earlier version of Xdebug:

check this out:
http://stackoverflow.com/questions/23251283/phpstorm-xdebug-cant-show-show-child-arrays-of-objects

Can you please take a look, maybe it is a same problem

Also tested:

$object1 = new stdClass();
$object1->someProperty = "o1";

    $object2 = new stdClass();
    $object2->someProperty = "o2";

    $storage = new SplObjectStorage();
    $storage->attach($object1);
    $storage->attach($object2);

And it falls with Xdebug ...

SplObjectStorage bug fixed in later version of PHP (7.0.6). Tried with 7.0.8 (working).
But still problem with "can not get property" (phpstorm 2016.2 + yii (or yii2)).

Please do not close issue, maybe someone can help.

Sorry, I still need a small reproducible script.

Hi I'm also having this problem and have tried 2.4.0, 2.4.1 and 2.4.2.

Unfortunately I've tried and failed to make a small reproducible script. The issue seems to arise when in the middle of production code involving a larger memory footprint, or more complex objects and array hierarchies. Many people on our team have the issue and it is really really frustrating - if you can give me some pointers in debugging xdebug on linux I'd be happy to try and debug for you (never debugged c code before!)

Andrew

acuthbert - can you at least provide a self contained re-reproducible case though? (And preferably, with Xdebug 2.5.0RC1).

Can't reproduce, and the requested feedback was not provided.

While I still don't have a minimal case, I managed to find a correlation between this bug's symptom in a production case and a similar symptom in a minimal case.

In the production case I am trying to expand a private property of a base class of $this, and I get the "can not get property" symptom. I can make the symptom go away by changing the property to protected or public.

In the minimal case I am working on, I get an "undefined property" notice when I try to expand a private property of a base class of $this. The notice also goes away when I change the property in the base class to protected or public.

This bug is ABSOLUTELY CRIPPLING. I am running into it ALL THE TIME but ONLY EVER when debugging large codebases.

There will be no SMALL reproducing script EVER.

You should probably downgrade your expecation of "short and self-contained" to just "self-contained", as in a vagrant box with a full Laravel project in it.

I have attached a minimal testfile, with which i am able to reproduce the problem.

Just set a breakpoint on the "exit;" and try to view the content of the inner class.

Xdebug v2.5.1
PHP 5.6.30
Linux 2.6.32 x86_64

Radiat-r, you're a genius.

I've confirmed this does reproduce the error on:

Xdebug v2.4.0
PHP 7.0.15

If this gets fixed it'll really help me. I can't understand why it's not a more commonly reported issue. That said we did interview a senior developer yesterday whose debug method was still print and exit; :(

derick can we get this issue reopened now there's a reproducible test case?

I still can't reproduce this with the attached test case. I've tried:

PHP 5.6.30, in ZTS and non-ZTS mode, with Xdebug 2.5.1 and 2.5.2-dev
PHP 7.0.15, in non-ZTS mode, with Xdebug 2.5.1
PHP 7.1.4-dev, in non-ZTS mode, with Xdebug 2.5.2-dev

also I had valgrind loaded to see memory/corruption issues.

In each case, I get the right answer, as is shown in the 1335.png attachment.

radiat-r, can you produce an Xdebug remote log with your debugging session?
Instructions are at https://xdebug.org/support.php#remote

And everybody, please make sure you're using at least Xdebug 2.5.1.

I have uploaded the requested logfile.

For privacy reasons, sensitive information has been removed and replaced with XXXXXXX.

This log has been taken from a different machine with PHP 7.1.3 and Xdebug v2.5.1 installed. The error shows up here as well.

Radiat-r - the simplified case you showed here has no privacy sensitive code, so if you say you can reproduce it with that, I would need a remote log to go with that specific script. And line numbers etc need to match exactly too.

The log was produced with that specific, unmodified script.

The sensitive parts were removed from the logfile, e.g. Cookie-Values, Hostname and Path-Information, which should be irrelevant to the case.

Adding my xdebug.log as well, remote log w/ no redaction.

PhpStorm 2017.1.2
PHP 7.0.16
Xdebug 2.5.1

Breakpoint on "exit" line, same error. This started lately with PHPStorm 2017 update, I may be chasing the wrong problem. I might downgrade and try again.

I have a hunch about what is causing this. I'll have an in depth look later.

I can reproduce this with PhpStorm 2017.1.3, but not with 2016.3.2. I need to check whether PhpStorm does it right, or Xdebug does it right.

I think I would say this is an unfortunate side effect of fixing a bug.

Xdebug sends the following packet containing:

<property name="middle\abstrct\abstractmiddleinner" fullname="$outer->middle->middle\abstrct
\abstractmiddleinner" facet="private" type="object" classname="inner\inner" children="1" numchildren
="3"></property>

The important bit being "$outer->middle->middle\abstrct\abstractmiddleinner" (which gets XML-decoded
to:

$outer->middle->middle\abstrct\abstractmiddleinner

It then constructs (in 2007.1.3) the following followup:

property_get -i 35 -n $outer->middle->middle\abstrct\abstractmiddleinner -d 0 -c 0 -p 0

It incorrectly adds the slashes here, as it does not use double quotes, which is needed if you add slashes. I think this was in order to be able to deal with things like bug https://youtrack
.jetbrains.com/issue/WI-34998 and https://bugs.xdebug.org/view.php?id=1305

It doesn't do that in 2016.3.2, where the command it constructs is:

<- property_get -i 35 -n $outer->middle->middle\abstrct\abstractmiddleinner -d 0 -c 0 -p 0

The adding of slashes was added due to https://youtrack.jetbrains.com/issue/WI-34998 and https://bugs
.xdebug.org/view.php?id=1305, which is only fixed in Xdebug 2.6dev.

So right now, the following combinations work:

Xdebug 2.5.x with PhpStorm 2016(.3.2)
or
Xdebug 2.6dev with PhpStorm 2017(.1.3).

Thanks derick - I'll give 2.6dev a go and let you know what I get.

acuthbert, any luck?

Sorry derick - it's probably obvious, but I can't see how to get 2.6dev - do I compile from source? But I can't see a 2.6 branch?

It's the master branch on GitHub, and yes, you compile it from source.

Oh course, no problem.

Sorry, derick, same problem for me on storm 2017.1.3 and 2.6dev (see attached screenshot)

derick, confusingly the test.php script does work correcly! But as the previous shot shows there issue can still be reproduced.

I'm going to need a way to reproduce that locally again then.

Hi Guys,

i just came across this issue. funny thing it runs on my notebook but not on my workstation.

i did some tests with different php versions and xdebug versions but with the same php code and same versions of php and xdebug i get "can not get property"
i checked all the xdebug config values on both systems

i stripped the code down to a minimun and can invite you to the repository

update: i just switched from phpstorm 2017 to the 2016 versions and somehow this works?! strange behaivor because on my notebook 2017 runs.

I've been able to reproduce this in a simple script, which i've attached to this ticket (xdebug.tar). It was a bit tricky (and took me all afternoon) due to requiring the use of namespaces before it manifests.

What seems to be happening is, as described, PhpStorm 2017.1.3 when talking to xdebug 2.6 is adding extra slashes to escape the name pathing bugs.

But it also looks like the deeper the properties you explore, the more "layers" of escaping are applied, and xdebug/phpstorm are in disagreement about how that's supposed to work.

This is seen in the xdebug logs:

<- property_get -i 17 -n $b->TestA\TestB\TestC\Adata1 -d 0 -c 0 -p 0
-> [... OK ...]

<- property_get -i 18 -n $b->TestA\\TestB\\TestC\\Adata1->items -d 0 -c 0 -p 0
-> [... can not get property ...]

Investigating deeper it looks like the failure is on PHP Storm's side, and relates to the xdebug 2.6-dev specific changes made here:
https://youtrack.jetbrains.com/issue/WI-35805

To that end I'll lodge a separate report with JetBrains and update this comment with a link back to that.

--

My local setup (same as 0001503):

Xdebug Version: 2.6(dev) 912eaeb8338d2945b6a424a1962e18fab854105b

PHP:
PHP 7.2.0 (cli) (built: Nov 28 2017 20:38:49) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.2.0, Copyright (c) 1999-2017, by Zend Technologies
with Xdebug v2.6.0dev, Copyright (c) 2002-2017, by Derick Rethans

Note it says "v2.6.0dev" only because I customised the version string to ensure it was actually using the compiled version, rather than the most recent "v.2.6.0alpha1" pre-compiled module, which also exhibits this bug.

IDE:
PhpStorm 2017.3.1
Build #PS-173.3942.32, built on December 13, 2017
Subscription is active until April 18, 2018
JRE: 1.8.0_152-release-1024-b8 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

Escaping issue reported to JetBrains: https://youtrack.jetbrains.com/issue/WI-39317

This is very much related to 0001514 and 0001515. I also believe PhpStorm does do it wrong currently.

I'm closing this, as on the Xdebug side everything now works. The test case log at https://github.com/xdebug/xdebug/blob/master/tests/bug01335.phpt#L25-L62 shows the right interaction. If PhpStorm does it differently (which, apparently, it does), it is a bug in PhpStorm. From what I gather, they're actively working on fixing this too.