symfony: Symfony displays a blank page instead of an error page under certain circumstances

I had some time today evening to create a test case for this bug.

php 7.1.8 symfony 3.3.6 any os

Steps to reproduce:

1. git clone --branch=bug-report/white-page-of-death https://github.com/d-ph/symfony-standard.git
2. cd symfony-standard\
3. composer install
4. php bin\console server:run
5. Go to http://127.0.0.1:8000/. Confirm it returns a pretty error page with error:

Error: Class MyApp\Foo contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (MyApp\AbstractFoo::bar)

1. Stop the server:run (ctrl-c).
2. vim app\AppKernel.php
3. Uncomment the new \Sentry\SentryBundle\SentryBundle(), line
4. php bin\console server:run
5. Go to http://127.0.0.1:8000/

Result: HTTP500 with white page of death.

Expected result: The same error page as in step 5.

More info: The issue is triggered after installing and enabling sentry/sentry-symfony, but I doubt that the problem lies in that package. I believe any code trying to register an error handler with set_error_handler AFTER Symfony\Component\Debug\ErrorHandler will trigger the problem. When it happens, then https://github.com/symfony/debug/blob/856a3e1/ErrorHandler.php#L563 :

        $handler = set_error_handler('var_dump');
        $handler = is_array($handler) ? $handler[0] : null;
        restore_error_handler();
        
        if (!$handler instanceof self) {
            return;
        }

will no longer want to handle any errors, because the registered error handler is not Symfony\Component\Debug\ErrorHandler.

Xdebug screenshot, when I get the pretty error page:

Xdebug screenshot, when I get the white screen of death:

I bet there are at least a couple of ways to solve it, but none of them would be pretty. It’s just php things again.

@xabbuh Yeah I can see if I can replicate this outside my project hopefully either tonight or tomorrow. I’ll be happy to contribute! 😄

@ErvinSabic Can you open a new issue with a description on how we can reproduce your issue?

@fabpot This might have resurfaced.

• I created a new bundle and added it to my composer.json
• Then I ran composer install
• I then began creating controllers for my bundle and noticed that all of my routes started returning blank pages.
• I thought maybe it was a weird caching issue so I ran php bin/console cache:clear and it returned a php exception. Related to a syntax error I had in one of the controllers.
• Came to the conclusion that Symfony is not displaying errors.

Also on my homepage route ( / ), I am getting a Javascript console error that says Uncaught ReferenceError: Sfjs is not defined. It only does this on that route. The other pages are fine. Although I am not sure if these issues are related.

Dev machine specs / environment: OS: Linux Mint 18.2 “Sonya” Symfony Version: 3.4.9 Symfony Environment: Dev Apache Version: Apache/2.4.18 PHP Version: 7.2.4 Composer: version @package_branch_alias_version@ (1.0.0-beta2) 2016-03-27 16:00:34 (Holy crap) Mysql Version: 5.7.20-0ubuntu0.16.04.1

This is related to the fact, that Symfony\Component\Debug\Debug disables error reporting, when the request is not run from cli ini_set(‘display_errors’, 0);. This is supposed to be fine, because the Debug component is registering its own error handler. The problem is that (probably: some) PHP’s Fatal Errors immediately crash the script without running those custom error handlers, which leaves devs with the white page of death. One of those Fatal Errors is:

Fatal error: Class FooBar contains 1 abstract method and must therefore be declared abstract or implement the remaining methods

(php 7.1.3, symfony 3.3.0 here)

---

(edit)

I couldn’t reproduce the problem with this particular error on fresh Symfony Standard project. Maybe I’ll fine some spare time later to isolate the cause of the problem from my current project.

Yes still happens in 3.3.2 too. Is there a new issue for this problem has this one is quit old ? But the first message is still relevant because it 's Debug::enable(); that leads to this weird behaviour. (+ other PHP error settings I suppose)

False alarm (bug not fixed). ./bin/console cache:clear did fix the issue with $foo->bar(). But the real error caused by $form->handleRequest($request); which ended up with the following fatal error PHP Fatal error: Call to a member function add() on null was not shown by Symfony.

Also note that display errors is on.

Symfony 3.1.2

php -v: PHP 5.6.11-1ubuntu3.4 (cli) Copyright © 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright © 1998-2015 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright © 1999-2015, by Zend Technologies with Xdebug v2.3.3, Copyright © 2002-2015, by Derick Rethans

uname -a 4.2.0-42-generic #49-Ubuntu SMP Tue Jun 28 21:26:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

The same problem also occurs in the current version of PHP, which is in actual debian repository.

PHP 5.4.4-14+deb7u14 (cli) (built: Aug 21 2014 08:36:44) 
    Copyright (c) 1997-2012 The PHP Group
    Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
  with XCache v2.0.0, Copyright (c) 2005-2012, by mOo
    +nginx

Fortunately, I solved it by replacing the function. I write just for info, if anyone was looking for.

Original code colleague:

    $response = new Response();
    $response->headers->setCookie(new Cookie('last', $id));
    $response->send();

Repaired on:

    $response = new Response();
    $cookie = new Cookie('last',$id, time() + 3600 * 24 * 7);
    $response->headers->setCookie($cookie);
    $response->sendHeaders();