No proper error page in case of fatal error when this bundle is activated

[hectorj]

Hi!

I'm having a small problem with this bundle:

When I activate it, Symfony doesn't handle PHP fatal errors anymore.

Let's say I have a $this->nonExistingMethod(); in one of my controller. Without this bundle, in prod env, Symfony displays a "pretty" HTML error page.

With this bundle, I get this instead:

My env is:
PHP 7.1
Symfony v3.3.10
sentry/sentry-symfony 0.8.6

[Jean85]

I was able to reproduce it on our prod env, sorry for the issue :( I'll try to debug it...

[hectorj]

From what I see, here we get a \Raven_ErrorHandler instead of a \Symfony\Component\Debug\ErrorHandler, so \Symfony\Component\HttpKernel\HttpKernel::terminateWithException (instantiated here and usually registered here) is never registered.

That's because \set_exception_handler is called by \Raven_ErrorHandler::registerExceptionHandler which is called by \Raven_Client::install which is called when Symfony instantiates it (following the config here), which happens when Symfony instantiates \Sentry\SentryBundle\EventListener\ExceptionListener, which happens when Symfony gets all the listeners for the KernelRequest event. (sorry for the run-on sentence).

Without the Sentry bundle, \Symfony\Component\Debug\ErrorHandler is the registered exception handler and \Symfony\Component\HttpKernel\HttpKernel::terminateWithException gets registered into it.

I'm still investigating more.

[hectorj]

To have the desired behavior, one way is to have \Raven_ErrorHandler register itself via \Symfony\Component\Debug\ErrorHandler::setExceptionHandler instead of \set_exception_handler, and only after \Symfony\Component\HttpKernel\EventListener\DebugHandlersListener::configure was executed (so it can get and use the \Symfony\Component\HttpKernel\HttpKernel::terminateWithException as its $this->old_exception_handler).

Or something like that 🤔

[Jean85]

I've closed #80 because it doesn't seem to fix the issue, and we shouldn't merge it as it is.

As said there, Sentry's and Symfony's error handlers are somehow colliding, creating double reporting (see #48) or losing the custom error page. I currently don't know how to fix this.

[DonCallisto]

@Jean85 could restore_exception_handler help there somehow?

Don't know where to place it btw

[Jean85]

Yes it could be helpful but the uncertainty here is very high. Symfony's error handler is the one that's bothering me, but we cannot be sure if that is the one immediately before ours: an other bundle could have added his handler in the middle.

I'm trying to set up an example Symfony project to test out better this issue.

[Jean85]

I currently cannot reproduce the issue locally. I've started a standard Symfony project, and just:

• used the official PHP7.1+Apache Docker container
• used this Apache virtualhost config (copied from SF's docs):

<VirtualHost *:80>
    DocumentRoot /var/www/symfony/web
    <Directory /var/www/symfony/web>
        AllowOverride All
        Order Allow,Deny
        Allow from All
    </Directory>

    ErrorLog /var/log/apache2/project_error.log
    CustomLog /var/log/apache2/project_access.log combined
</VirtualHost>

• installed this bundle (as the last one in AppKernel)
• configured the Sentry DSN
• created a custom error template in app/Resources/TwigBundle/views/Exception/error.html.twig
• added a trigger_error('TEST', E_USER_ERROR) in the action

...but the custom error template is always showing, and Sentry is always reporting the errors correctly (with duplication when it's not a \Throwable, but that's a separate issue).

I don't know what to change now to trigger this issue; maybe we're using some strange webserver config that throws Symfony/Twig off?

[gondo]

i've just experienced the same problem.
Symfony 2.8
error triggered via random string (not valid php) placed in action:

indexAction(Request $request) {
    random string to trigger error
}

[Jean85]

I've taken an other step further to recreate the issue locally by replacing the ExceptionController instead of replacing the templates, but still no reproduction.

[Jean85]

Closing this as not reproducible. Feel free to reply with a reproducible case and I will reopen it.