21

I have a issue with my Drupal installation, for example:

  • when I enable or disable the modules, It redirects me to a blank page,
  • when I create a new content type and save it, redirects me to a blank page,
  • when I add a new view and save it, it redirects me to a blank page,
  • when I try to clear the cache, it redirects me back to a blank page,
  • or in similar cases.

Basically all the confirmation pages redirect me to a white screen. When I refresh it again, it shows me the page. I tried to increase the PHP memory value but it doesn't help.

Are there any other solutions for this?

The error which I'm having:

Fatal error: Allowed memory size of 100663296 bytes exhausted (tried to allocate 8192 bytes) in sites/all/modules/views/plugins/views_plugin_localization_none.inc on line 1

1
  • 3
    Always check the error logs, it will have all the info needed. Sounds like in your case you are running out of Memory. Drupal 7 requires more than 32MB which many of host providers set it as a default.
    – GoodSp33d
    Dec 27, 2012 at 16:36

6 Answers 6

20

I know this may be late, but it helped me. Most times a module causes WSOD, I couldn't just disable modules to test which it was, since I may have lost data in the process. What I did was to temporarily edit this function in module.inc, in the core includes directory

function module_invoke_all($hook) {
  $args = func_get_args();
  // Remove $hook from the arguments.
  unset($args[0]);
  $return = array();
  foreach (module_implements($hook) as $module) {

        print "Starting loading $module <br />";

        $function = $module . '_' . $hook;
        if (function_exists($function)) {
          $result = call_user_func_array($function, $args);
          if (isset($result) && is_array($result)) {
            $return = array_merge_recursive($return, $result);
          }
          elseif (isset($result)) {
            $return[] = $result;
          }
        }

        print "Finished loading $module <br />";

  }

  return $return;
}

And I added those 2 print statements in the code above, then refresh the page, the module which didn't reach the "Finish loading $module" statement is the one with the problem... it was devel in my case.

After finding the module, you can go into the system table and look for that module, set it's status = 0 and bootstrap = 0 or run the query:

UPDATE system SET status = 0, bootstrap = 0 WHERE name = 'module_name' LIMIT 1

Reference: Debugging Drupal White Screen of Death (WSOD)

2
  • 1
    Adding the print statements to module_invoke_all allowed me to quickly find the offending module. Then I used drush to disable it. What a life-saver!
    – Dan Meigs
    Mar 1, 2014 at 18:15
  • You're welcome @DanMeigs. I have used this method only today to fix my blog cleverlogic.net. Maybe I do should write an article on this, cuz I sure did read a lot whiles trying to get the WSOD fixed Mar 1, 2014 at 18:29
12

Paste this code in your index.php file. It will show you the error message instead of blank page. At least the root of the problem can be known. Paste it right after php tag.

    error_reporting(E_ALL);
    ini_set('display_errors', TRUE);
    ini_set('display_startup_errors', TRUE);

Hope it will show you the way!.

http://drupal.org/node/158043

4
  • 1
    That didn't work, I tried that yesterday to see the errors, but it doesn't print anything
    – Jayaram
    Dec 27, 2012 at 16:23
  • 4
    Have you checked your error log? If you're running Apache on Linux, try this command in the terminal: tail /var/log/apache2/error.log. That will show you the 10 most recent lines of that file. Dec 27, 2012 at 16:31
  • Actually, it started showing me the errors.. The error I get is Fatal error: Allowed memory size of 100663296 bytes exhausted (tried to allocate 8192 bytes) in ***/sites/all/modules/views/plugins/views_plugin_localization_none.inc on line 1
    – Jayaram
    Dec 27, 2012 at 21:18
  • 1
    Adding this to index.php is a bad idea (even temporary, as most people are to lazy to remove it later on if this works), it's better to paste it straight into your settings file.
    – kenorb
    Jul 24, 2015 at 9:39
11

Reason of blank white screen of death is the error reporting turned off, to check the error add the following lines in your setting.php file:

error_reporting(E_ALL);
$conf['error_level'] = 2;
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

For the error you are facing("Allowed memory size of XXX bytes exhausted"), you can try the following things:

  1. Truncate the cache manually and check if it fixes the problem ( It is probably be a good to backup your DB before doing that):

    Access phpMyAdmin and truncate all tables starting by cache_ from the database.

  2. Increase the memory limit (as the main reason of the above error is the memory exhausted by the server which caused the partial loading of the modules and that is causing the problem) by adding the following line in your settings.php file: ini_set('memory_limit', '-1');
    Adding ini_set('memory_limit', '-1'); overrides the default PHP memory limit.
    If you want to restrict the memory than instead of -1 you can provide memory size like '256M' OR '512M'.

9

The error:

Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)

To convert bytes X into MB, divide by 1024*1024 or check at Wolfram.

happens when PHP tries to allocate Y bytes, but there is hard limit on X bytes set by PHP memory_limit configuration settings.

The current limit can be checked by going to Administration » Reports » Status report » PHP (URL: /admin/reports/status/php) or by printing ini_get('memory_limit') in PHP (note that limit be different for UI and CLI).

In order to fix it, you need to lower your resource usage, for example:

  • disable any development modules which you're not using currently (recommended),

    This includes: Devel, Devel Themer (if enabled).

  • disable any modules which you're not using,

  • disable certain debug variables which can impact on your memory resources, e.g. few examples with drush:

    drush -y vset rules_debug 0
    drush -y vset rules_debug_log 0
    
  • disable certain PHP extensions, such as XDebug,

  • enable redis/memcached caches and some PHP caches (e.g. OPCache/XCache),
  • finally if above won't help - increase memory_limit in your PHP configuration.

If you decide on increasing memory limit, a lot of people here advising to actually hack your core by pasting the PHP code into your index.php to increase your PHP memory - never do that! It's a very bad practise.

Instead edit your settings.php (or settings.local.php if you have it included) and paste the following code there at the end:

ini_set('memory_limit', '512M');

or a better way of doing this is to edit your PHP config file (php.ini) and changing the following line:

memory_limit = 512M  ; Maximum amount of memory a script may consume

If you're not sure where is your php.ini, check by:

  • drush status command
  • or by going at /admin/reports/status/php.

To investigate further which pages/components are using the most memory, you've the following possibilities:

For further information, check:

1
  • 2
    +1 for stressing that php UI and CLI can have different memory_limit. I had the reported problem only with drush exactly because I had an error in /etc/php/7.0/cli/php.ini but not in /etc/php/7.0/cli/php.ini, so drupal UI was working fine. Thanks! May 8, 2016 at 20:23
7

It could very well be that one of your modules is running out of memory.

You can add one line of code to your index.php file to allow Drupal to run with more memory than the default setting:

ini_set('memory_limit','256M');

Add the above code on the line after the ?php in your /drupal/index.php file. If everything starts working fine, then you can identify what is causing the memory problem (highly likely it's a module).

Disable a module, and then comment out the ini_set('memory_limit','256M'); and see if it loads now.

It is not recommended to leave the ini_set('memory_limit','256M'); in place as a solution, but it can at least allow you to get to your module listing page.

You may find it helpful to do a debug_backtrace() to determine what was using the memory.

4
  • This didn't help
    – Jayaram
    Dec 27, 2012 at 21:11
  • Also, I can see the modules list page, it only happens when I enable/disable modules, I would have to refresh it again to see the confirmation page.
    – Jayaram
    Dec 27, 2012 at 21:15
  • 3
    Rather than putting ini_set() calls in index.php, where they will get wiped out on an update, if you have to code them in PHP you should put them in your settings.php file, which is the correct place for site-specific overrides. May 15, 2013 at 8:51
  • Adding this to index.php is a bad idea (even temporary, as most people are to lazy to remove it later on if this works), it's better to paste it straight into your settings file.
    – kenorb
    Jul 24, 2015 at 9:40
2

You can use a module to control this memory limit. PHP Runtime Configurator module provides many options to configure without changing your php.ini file and restart Apache.

You can configure following parameters:

  • File Upload Limit
  • Memory Limit
  • Maximum Execution Time Limit
  • Maximum Input Variable Limit

Not the answer you're looking for? Browse other questions tagged or ask your own question.