Deep nested arrays yield useless output in Symfony\Component\Debug #10292

Closed
ddebernardy opened this Issue Feb 19, 2014 · 6 comments

6 participants

@ddebernardy

To reproduce, use the following in the global scope before booting the Kernel:

Debug::enable();
$a->b;

That yields an unreadable screen of tight and hard to read text:

ContextErrorException: Notice: Undefined variable: a in /Users/denis/Sites/wp/www/app-load.php line 28
in /Users/denis/Sites/wp/www/app-load.php line 28
at ErrorHandler->handle('8', 'Undefined variable: a', '/Users/denis/Sites/wp/www/app-load.php', '28', array('GLOBALS' => array('GLOBALS' => array('GLOBALS' => array('GLOBALS' => array('GLOBALS' => array('GLOBALS' => array('GLOBALS' => array('GLOBALS' => array('GLOBALS' => array('GLOBALS' => array('GLOBALS' => array(*DEEP NESTED ARRAY*), '_POST' => array(*DEEP NESTED ARRAY*), '_GET' => array(*DEEP NESTED ARRAY*), '_COOKIE' => array(*DEEP NESTED ARRAY*), '_FILES' => array(*DEEP NESTED ARRAY*), '_ENV' => array(*DEEP NESTED ARRAY*), '_REQUEST' => array(*DEEP NESTED ARRAY*), '_SERVER' => array(*DEEP NESTED ARRAY*), 'loader' => object(ClassLoader), …

I'm not entirely sure what the best approach to fix this would be, but in the case of $GLOBALS, shouldn't the exception handler ideally unset $GLOBALS['GLOBALS']?

@jakzal jakzal added the Debug label Feb 19, 2014
@aeryaguzov

Provide full listing from your app-load.php, please, to reproduce your case.

@ddebernardy

Symfony standard, access an undefined property immediately after Debug::enable().

The Debug component is useful when the exception is scoped within a function or method. Not so much when the error occurs in the global scope (which can happen, as in my case, when integrating SF with software such as WordPress.)

@fabpot
Symfony member
@stof
Symfony member

I think we should indeed clean a bit the context before setting it in the ContextErrorException to avoid the self-reference of globals.
It will still happen if you have recursions in other places, and handling them would be too much work IMO, it is the job of the renderer. But $GLOBALS could be handled

@nicolas-grekas

For the specific behavior described here, $GLOBALS is not part of $context anymore since PHP 5.4 (http://3v4l.org/SCdKX) so I'm going to make a patch to ContextErrorException for handling this.

For arbitrary nested structures, #10640 is the answer :)

@stof
Symfony member

@nicolas-grekas I agree.

@nicolas-grekas nicolas-grekas added a commit to nicolas-grekas/symfony that referenced this issue Apr 28, 2014
@nicolas-grekas nicolas-grekas [Debug] fix #10292 aa38af7
@fabpot fabpot added a commit that referenced this issue Apr 28, 2014
@fabpot fabpot bug #10799 [Debug] less intrusive work around for https://bugs.php.ne…
…t/54275 (nicolas-grekas)

This PR was merged into the 2.5-dev branch.

Discussion
----------

[Debug] less intrusive work around for https://bugs.php.net/54275

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #10787, #10292
| License       | MIT
| Doc PR        | none

- This PR supersedes the behavior introduced in #10725 :
  Instead of building some complicated code to work around https://bugs.php.net/54275, the code is now as
  straightforward as possible, with a conditional fallback work around.
- The handling of fatal errors is also made more robust/fail-safe.
- Last but not least, ErrorsLoggerListener and FatalErrorExceptionsListener are now registered earlier and
  are now cleaning up their handler/logger once set to prevent setting again and again for sub-requests
  (+remove one refcount for these handler and logger).

Commits
-------

d7a186f [Debug] less intrusive work around for https://bugs.php.net/54275
21ea038
@fabpot fabpot added a commit that referenced this issue Apr 28, 2014
@fabpot fabpot bug #10801 [Debug] ErrorHandler: remove $GLOBALS from context in PHP5…
….3 fix #10292 (nicolas-grekas)

This PR was merged into the 2.3 branch.

Discussion
----------

[Debug] ErrorHandler: remove $GLOBALS from context in PHP5.3 fix #10292

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #10292
| License       | MIT
| Doc PR        | none

Commits
-------

ed0ed80 [Debug] ErrorHandler: remove $GLOBALS from context in PHP5.3 fix #10292
48f26f7
@fabpot fabpot closed this Apr 28, 2014
@fabpot fabpot added a commit that referenced this issue Apr 28, 2014
@fabpot fabpot Merge branch '2.3' into 2.4
* 2.3:
  [Debug] ErrorHandler: remove $GLOBALS from context in PHP5.3 fix #10292
  Allow File instance to be passed to BinaryFileResponse
  Add upgrade instructions for the LoggerInterface
  fixed CS
  Removed strict check when found variables inside a translation
b1c4ece
@fabpot fabpot added a commit that referenced this issue Apr 28, 2014
@fabpot fabpot Merge branch '2.4'
* 2.4:
  [Debug] ErrorHandler: remove $GLOBALS from context in PHP5.3 fix #10292
  Allow File instance to be passed to BinaryFileResponse
  Add upgrade instructions for the LoggerInterface
  fixed CS
  Removed strict check when found variables inside a translation
  [ExpressionLanguage] Test for the non-strict in_array check in parsePrimaryExpression in Parser.php
  Strict in_array check in Parser.php
  Updated Serbian latin validation translation

Conflicts:
	src/Symfony/Component/Debug/ErrorHandler.php
63d1255
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment