8000 [Debug] Remove GLOBALS from exception context to avoid endless recursion by Seldaek · Pull Request #20519 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Debug] Remove GLOBALS from exception context to avoid endless recursion #20519

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 15, 2016

Conversation

Seldaek
Copy link
Member
@Seldaek Seldaek commented Nov 14, 2016
Q A
Branch? 2.7
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed ticket #20347
License MIT

This fixes a endless recursion as seen in felixfbecker/php-language-server#137 - it only happens if you trigger an error in the global context so it's kinda hard to write a test for, but hopefully the fix can be accepted.

@nicolas-grekas
Copy link
Member

This piece of code changed in 3.2, are you sure the issue is on <= 3.1?

@Seldaek
Copy link
Member Author
Seldaek commented Nov 14, 2016

I could repro with 3.1.6, not sure about 3.2 though, but in general I find it surprising/disappointing that this whole code reinvents exception serialization instead of passing on the raw exception object to the logger context as defined in PSR-3, which would have allowed monolog to serialize it well in this case. Obviously I am a bit biased but still.

@nicolas-grekas
Copy link
Member

So, check 3.2, which does just that :)

@Seldaek
Copy link
Member Author
Seldaek commented Nov 15, 2016

OK I can confirm that on symfony master the bug isn't there anymore, that's great! I don't know if we should merge this fix anyway for lower versions or not. It's kind of an edge case that something bad happens on the global scope these days, so up to you.

@stof
Copy link
Member
stof commented Nov 15, 2016

I'm still in favor of fixing such tricky edge case (especially when we have the fix), as infinite loops in the error handling makes debugging very hard

@nicolas-grekas
Copy link
Member
nicolas-grekas commented Nov 15, 2016

Looking a few lines above, I'd say let's unset GLOBALS all the time, no matter which PHP version is in use. The fix should be just removing the PHP version check from this line.
Note also that this applies to 2.7 so should rebased.

@Seldaek
Copy link
Member Author
Seldaek commented Nov 15, 2016

Ah I thought 2.7 was EOL sorry :) I'll rebase, and you rather do the unset above there without any condition around it is that right?

8000

@nicolas-grekas
Copy link
Member

I'd keep the if, but remove the first check for the PHP version.

@Seldaek
Copy link
Member Author
Seldaek commented Nov 15, 2016

OK thanks, I'm asking because I have no idea what the rest is about and don't really have time to dig in :)

@Seldaek Seldaek changed the base branch from 2.8 to 2.7 November 15, 2016 12:38
@Seldaek
Copy link
Member Author
Seldaek commented Nov 15, 2016

Alright let me know if there's anything else I can do here

@nicolas-grekas
Copy link
Member

Thank you @Seldaek.

@nicolas-grekas nicolas-grekas merged commit 1bb95ac into symfony:2.7 Nov 15, 2016
nicolas-grekas added a commit that referenced this pull request Nov 15, 2016
…less recursion (Seldaek)

This PR was merged into the 2.7 branch.

Discussion
----------

[Debug] Remove GLOBALS from exception context to avoid endless recursion

| Q             | A
| ------------- | ---
| Branch?       | 2.7
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| License       | MIT

This fixes a endless recursion as seen in felixfbecker/php-language-server#137 - it only happens if you trigger an error in the global context so it's kinda hard to write a test for, but hopefully the fix can be accepted.

Commits
-------

1bb95ac [Debug] Remove GLOBALS from exception context to avoid endless recursion
@sstok
Copy link
Contributor
sstok commented Nov 15, 2016

FYI http://symfony.com/roadmap?version=2.7#checker
May 2018 End of support for bug fixes

@antograssiot
Copy link
Contributor

This causes BC break for us while upgrading from 3.1.6 to 3.1.7 as we are wrapping a legacy codebase highly coupled to $GLOBALS unfortunately during a progressive migration.
Is there any chance to get this PR reverted ?
@Seldaek @nicolas-grekas

@Seldaek
Copy link
Member Author
Seldaek commented Dec 6, 2016

@antograssiot should be easy to add a monolog processor that adds $GLOBALS (or a subset) to the context or extra data of log records if you really want.. I think this stuff is way better done in the app than the framework as it depends on application specific knowledge.

@philippecarle
Copy link

@Seldaek what @antograssiot said is more about the issue introduced by the unrecoverable and unconfigurable deletion of $GLOBALS. Our case (we're teammates fyi) is that we have a wrapped legacy system which is "called" by the symfony app when the request can't be processed by symfony (exceptions thrown by includes of legacy files are catched and handled...). It is kind of a classical, clean and smooth progressive migration pattern. The legacy system relying on $GLOBALS is fully broken: OK, we all agree about how dramatic it is but hey, sometimes reality is just as it is ;).
At this point, and it may needs some more investigations to be called a "solution", I was only able to override the definition of debug.debug_handlers_listener in a compiler pass to change the $scream to false : it is definitely ugly and prevent us from having any silenced PHP notices.

@nicolas-grekas
Copy link
Member

How does this relate to your app? I mean, did you do some integration with the $context argument? Or are you using a logger that needs the GLOBALS index in its own context argument? Or do you need GLOBALS in thrown exceptions? Or is there some side effect not related to any of these that changed with this?

@philippecarle
Copy link

I created a repository to illustrate exactly our use case : https://github.com/philippecarle/symfony-globals

Here is a brief explanation of our application behavior : the app.php tries to handle the request as it uses to, but in case of thrown NotFoundHttpException, the legacyhandler service tries to resolve the path in the /legacy folder and handle either the response or the exception.

I put a legacy/test/test.php file to illustrate what happens, dumping $GLOBALS once, triggering an error (in my case an undeclared variable) and dumping the $GLOBALS again. In 3.1.6 it was ok, but the 3.1.7 just cleans the globals.

Our legacy code intensively relies on globals, so it makes us being stuck in 3.1.6. We may find a not-too-tricky way to disable errors handling for the legacy code, but it would prevent us from using the debug section of the profiler, which is very useful for us in our everyday work of optimization of the legacy code.

Any ideas / suggestions ?
Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants
0