-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Console][FrameworkBundle] Broken exception handler on console #25718
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
Comments
The while loop could additionally check if the handler is still changing or staying the same. Or have a same-count to abort after a while if the handler keeps being the same. That would cover situations like the newrelic plugin messing with restore_exception_handler. |
That's a bug in the New Relic extension, isn't it? it changes the original behavior of the engine. |
it sounds like a dangerous feature in new relic. i guess they really don't want to be unhooked, so that they can always report bugs... given how hacky the while loop is, i think it should have some sort of safety valve to realize such a thing - a specific check for newrelic would not work for other extensions that might do the same thing, and could break anytime if newrelic renames their callback. also, i think at least for us, the problem would be completely hidden if the problem @mjanser describes would not happen: console application hooks an error callback, then boots kernel which adds the debug error callback, then console application terminates and blindly pops the last error callback, which happens to be the debug error callback. then later the debug error callback tries to find itself in the list, which does not work. i wonder why we need any of that - can't we store $this in a static variable in the debug ErrorHandler class so that it can be accessed again without removing and re-adding error handlers? |
I agree with @dbu, just for completeness: the exception handler of New Relic is a function named |
… fancyweb) This PR was merged into the 3.4 branch. Discussion ---------- [Console] Fix restoring exception handler | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | ,p | Tests pass? | yes | Fixed tickets | #25718 | License | MIT | Doc PR | - Commits ------- 0096449 [Console] Keep the modified exception handler 3fa1ad9 [Console] Fix restoring exception handler
#25255 introduced an own exception handler in
Console/Application.php
before the kernel is booted. During kernel boot and if the framework-bundle is installed, it registers the exception handler of the debug component (Debug/ErrorHandler.php
). When the command has ended the exception handler is restored inConsole/Application.php
, but this actually removes the handler ofDebug/ErrorHandler.php
and leaves the handler ofConsole/Application.php
registered.This behaviour seems unintended and wrong to me.
Additionally
Debug/ErrorHandler.php
registers a shutdown function to handle fatal errors. This depends on the exception handler being itself, but that's not the case in the above described situation. With the while loop introduced in #25408 it falls back the defaultnull
exception handler and then does nothing.If New Relic is added to the setup that while loop will never end because the New Relic extension always returns its own exception handler by default (instead of
null
for PHP default handler).The text was updated successfully, but these errors were encountered: