调试 Drupal 的白屏死机？答案

【问题标题】：Debugging Drupal's White Screen of Death?调试 Drupal 的白屏死机？
【发布时间】：2011-08-26 22:02:11
【问题描述】：

我有一个以前在我的本地主机上完美运行的 Drupal 安装。但是，现在，我的电脑格式化后，它只是显示一个空白屏幕（全白）。

所以我的问题是，如果我什至无法登录服务器，我怎么能看到哪里出了问题？

我能找到的唯一错误是（取自 Apache 错误日志）：

[Tue May 17 05:05:04 2011] [notice] Parent: child process exited with status 255 -- Restarting.
[Tue May 17 05:05:04 2011] [notice] Digest: generating secret for digest authentication ...
[Tue May 17 05:05:04 2011] [notice] Digest: done
[Tue May 17 05:05:07 2011] [notice] Apache/2.2.11 (Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i PHP/5.2.9 configured -- resuming normal operations
[Tue May 17 05:05:07 2011] [notice] Server built: Dec 10 2008 00:10:06
[Tue May 17 05:05:07 2011] [notice] Parent: Created child process 6992

Watchdog 中没有错误...

我正在使用 Xamp 1.7.1 (PHP 5.2) 和 Drupal 6。

我还需要提一下，一旦我尝试在本地计算机上加载站点，apache 也会崩溃！我添加了这个：

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

它仍然只是显示死亡屏幕？我实际上在哪里可以看到错误？

我也在 apache access.log 中找到了这个：

127.0.0.1 - - [17/May/2011:05:22:14 +0200] "GET /greekmerchant/src/ HTTP/1.1" 200 3
127.0.0.1 - - [17/May/2011:05:25:45 +0200] "GET /greekmerchant/src/update.php HTTP/1.1" 302 -
127.0.0.1 - - [17/May/2011:05:25:46 +0200] "GET /greekmerchant/src/update.php?op=info HTTP/1.1" 200 -

... 在尝试访问 update.php 之后。它也只是进入白屏。

我的 sql 配置文件中有这个：

[mysqld]
port= 3306
socket= "C:/xampp/mysql/mysql.sock"
basedir="C:/xampp/mysql" 
tmpdir="C:/xampp/tmp" 
datadir="C:/xampp/mysql/data"
skip-locking
key_buffer = 16M
max_allowed_packet = 128M
table_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
log_error="mysql_error.log"

还有……

[mysqldump]
quick
max_allowed_packet = 128M

另外，我的 PHP 内存设置为 1024MB。

有人知道为什么这会死吗？真的是内存问题吗？我还能做些什么来向我显示错误？即使启用错误日志记录，我仍然什么也看不到。

更新：

如果我删除文件夹，该网站将在我的本地计算机上运行。因此，由于某种原因，当它必须访问文件夹中的文件时，它会耗尽内存。为什么？或者更好的是，什么可能导致过度使用内存？

【问题讨论】：

您安装了多少个模块（大约）？尝试通过 pphpMyAdmin 清空缓存表。之后重试访问该页面。如果 apache 崩溃，请再试大约 5 到 6 次。我在内存不足的服务器上也遇到了类似的问题。 Drupal 能够通过多个请求重建缓存。顺便说一句，apache 会立即崩溃还是需要几秒钟？翻译文件可能存在于文件下，如果您有很多模块和激活的语言，可能会导致创建时出现内存问题。在创建缩略图时，图像缓存也会导致问题。

标签： php apache debugging drupal-6 wsod

【解决方案1】：

Drupal 手册中有一整页专门用于调试“White Screen of Death”。简而言之，通过在 index.php 文件的顶部添加以下内容来启用错误报告：

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

...并检查您已经开始执行的日志。在大多数情况下，这两个步骤往往会查明问题。如果这不能为您指明解决方案，请继续阅读手册页面，了解更多提示。

如果我不得不大胆猜测，我会说您的情况可能是内存不足错误。

【讨论】：

我同意它内存不足。那么你如何解决这个问题？我有 4 gigs 的 RAM ......我如何提升我的本地机器来利用它？
您可以按照此处的说明增加内存限制：drupal.org/node/31819
在阿拉斯加尝试 Wolf Fence：在代码中的某个位置放置 print "Hi, Mom!"。刷新。你明白吗？如果没有，请在执行中更早地放置它。如果你确实得到它，请稍后放置。起泡，冲洗，重复。您可以很快将其缩小到一两行代码。
我用 update.php 做到了，它一直到： print theme('update_page', $output, !$progress_page); --> 但那什么也没显示？我什至禁用了所有主题！
我认为在 PHP 代码中启用 display_startup_errors 没有任何用处。该设置 - 即使在那时启用 - 也设置得太晚了。这些错误已经发生。

【解决方案2】：

检查您的 PHP 错误报告设置。您可能需要启用错误报告。

这可能会有所帮助：http://drupal.org/node/158043

【讨论】：

【解决方案3】：

theme('page') 渲染的内容是空的，那肯定会给你一个WOD。

使用this 来帮助您，它会发现一些与WOD 相关的常见问题。

也尝试重建权限，最好的方法是使用 drush 并输入：

drush php-eval 'node_access_rebuild();'

也可以使用 drush 查看当前安装的模块，用

drush sm

禁用所有自定义模块，然后搜索。

drush disable <modulename>

当你在匆忙中，清除缓存：

drush cc

如果您认为 cron 是问题所在，我之前曾遇到过写得很糟糕的 cron 挂钩的巨大问题，以防万一这是您的问题，supercron 将成为您的朋友。

你应该有足够的内存，除非你的某些模块表现非常很糟糕。

* 故障排除更新

如果在运行 update.php 时出现问题，请在文本编辑器中打开 update.php 并取消注释以下行：

ini_set('display_errors', FALSE);

请参阅this page 了解其他 wsod 修复。值得注意的是，如果您使用 path-auto，则该页面上提到的修复值得一看。

【讨论】：

【解决方案4】：

我的建议是获取模块和主题文件夹的全部内容并将它们下载到您的桌面。这些主题和模块仍然安装，只是暂时禁用。如果您的网站回来了，那么很可能是模块或主题错误。也许有人错过了一个结束括号'}'。如果您确定模块或主题不是问题，则将它们放回文件夹中，不会有任何损失。试试这个并没有什么坏处，因为你不会失去任何东西。如果您发现这是一个模块问题，请开始将它们一一放回文件夹中，一路刷新。一旦站点出现白屏，您就会发现问题，更新模块可能会有所帮助。

我总是先尝试这个，因为 drupal 安装非常可靠，它是您必须担心的模块和主题。

与此处的其他答案不同，这不会准确指出问题，但是如果您像我一样懒惰并且不想修改配置文件并打开错误，那么这就是要走的路，或者至少从这里开始然后走并在所有其他方法都失败时修改配置。

【讨论】：

【解决方案5】：

假设它是 Linux 主机，如果您的主机运行的是 suPHP 或其他形式的 suexec，则可能是权限问题。确保文件的所有权正确，访问方式正确。

您可能还有一个无效的 .htaccess 文件，请尝试将其删除以进行测试。

【讨论】：

【解决方案6】：

在我的php.ini 中我修改了这些变量：

error_reporting = E_ALL & ~E_DEPRECATED
display_errors = On 
display_startup_errors = On

执行：

sudo apachectl restart

在我所有的 Drupal 站点中摆脱这些错误。

【讨论】：

【解决方案7】：

我知道这可能会迟到，但它帮助了我。大多数时候一个模块会导致 WSOD，我不能只禁用模块来测试它是什么，因为我可能在这个过程中丢失了数据。我所做的是在module.inc中编辑这个函数

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;
}

我在上面的代码中添加了这 2 个打印语句，然后刷新页面，没有到达“完成加载 $module”语句的模块是有问题的......在我的情况下是开发.

找到模块后，您可以进入系统表并查找该模块，将其设置为状态 = 0 和引导 = 0 或运行查询：

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

参考：Debugging Drupal White Screen of Death (WSOD)

【讨论】：

【解决方案8】：

有一个 WSOD，它不会告诉我出了什么问题。启用display_errors/display_startup_errors/error_reporting后没有出现错误。 PHP 错误日志中没有任何内容。服务器错误日志中没有任何内容。只需一个 WSOD 就可以了。

我最终设法诱使 Drupal 显示错误消息的方法是启用 $update_free_access = FALSE; 并导航到 /update.php。这表明没有待处理的更新，但在数据库中列出了一大堆错误，这是数据导入混乱的结果。

【讨论】：

【解决方案9】：

在marinelli 主题中，缺少文件夹逻辑会导致此类问题。

【讨论】：