PHP 生成一个完全白色的页面，没有错误、日志或标题。
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1944105/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
PHP produces a completely white page, no errors, logs, or headers.
提问by Xeoncross
While running some PHP code on my private WAMP PC I'm suddenly getting a blank response from the server - no response actually. No headers, no data, nothing in the PHP error logs, nada. I restarted APACHE and PHP but still nothing. I know php is working because I can access other PHP scripts just fine.
在我的私人 WAMP PC 上运行一些 PHP 代码时，我突然收到来自服务器的空白响应 - 实际上没有响应。没有标题，没有数据，PHP 错误日志中没有任何内容，nada。我重新启动了 APACHE 和 PHP，但仍然没有。我知道 php 正在运行，因为我可以很好地访问其他 PHP 脚本。
Firebug reports no headers, ? bytes, and it only takes 163msto "load" (so it's not a timeout). I thought about rapid memory consumption - but I monitored my PC's memory and it's not showing any spikes. Errors and Exceptions have been working fine until now.
Firebug 报告没有标题， ? 字节，“加载”只需要163 毫秒（所以它不是超时）。我想过快速的内存消耗 - 但我监控了我的 PC 的内存，它没有显示任何峰值。到目前为止，错误和异常一直运行良好。
What in the world?
世界上有什么？
max_execution_time = 30 ;
max_input_time = 60 ;
max_input_nesting_level = 64 ;
memory_limit = 500M ;
error_reporting = E_ALL | E_NOTICE | E_STRICT
display_errors = On
log_errors = On
:EDIT:
：编辑：
I wouldn't touch @with a ten-foot-pole. I think the ruby guys throw that in there so programmers would drop PHP.
我不会碰@一根十英尺长的杆子。我认为 ruby 家伙把它扔在那里，所以程序员会放弃 PHP。
Anyway, I enabled xdebug and it didn't output any grind files. Then I took zombat's advice and placed a DIE() at the top of the page and it worked. I guess that I just have some very weirdcode that totally kills PHP. Even if errors were disabled or suppressed with @I should still be getting back a header from the server with the empty content!
无论如何，我启用了 xdebug 并且它没有输出任何研磨文件。然后我接受了 zombat 的建议并在页面顶部放置了一个 DIE() 并且它起作用了。我想我只是有一些非常奇怪的代码可以完全杀死 PHP。即使错误被禁用或抑制，@我仍然应该从服务器获取空内容的标头！
If I find more I'll post back.
如果我发现更多我会回帖。
采纳答案by Xeoncross
I guessed the answer to this problem - it turns out that PHP 5.2.5 can't handle a recursive death.
我猜到了这个问题的答案——结果是 PHP 5.2.5 无法处理递归死亡。
<?php
class A
{
public function __construct()
{
new B;
}
}
class B
{
public function __construct()
{
new A;
}
}
new A;
print 'Loaded Class A';
No headers, errors, content, logs, xdebug dumps, memory spikes, CPU spikes, server crashes, or anything. After about 150ms PHP just "ends". Weird.
没有标题、错误、内容、日志、xdebug 转储、内存峰值、CPU 峰值、服务器崩溃或任何东西。大约 150 毫秒后，PHP 就“结束”了。奇怪的。
回答by Mike B
Run the page from a console and you'll get the error message.
从控制台运行该页面，您将收到错误消息。
// nix
php yourFile.php
// Windows
c:\path\to\php.exe yourFile.php
回答by zombat
You say other PHP scripts are working, so that indicates it's probably not an Apache problem. You also appear to have all your logging settings correct, and nothing is getting logged, so it's quite possible PHP is exiting normally before it outputs anything. One of the following could be true:
您说其他 PHP 脚本正在运行，因此这表明它可能不是 Apache 问题。您似乎还正确设置了所有日志记录，并且没有记录任何内容，因此很可能 PHP 在输出任何内容之前正常退出。以下情况之一可能为真：
- A misplaced
exit()statement? You were working on the code, maybe you added a quickexit()to check something out, and forgot to remove it? - don.neufeld's idea of checking for the use of the
@operator, which suppresses any error messages, has cost me hours of debugging time in the past. Definitely something to look for.
- 错位的
exit()说法？您正在处理代码，也许您添加了一个快速exit()检查的东西，但忘记删除它？ - 在过去，don.neufeld 检查
@运算符使用情况的想法会抑制任何错误消息，这让我花费了数小时的调试时间。绝对是要寻找的东西。
In situations like this, the poor man's debugging approach can yield some quick results. Throw an exit('wtf');in as the first line in the script in question here. Does that run? The results of that test immediately rules out all sorts of possibilities no matter what the result is. If you don't get any output, then it's probably a server-level problem (configuration, bad module, etc), although be careful of any higher-level buffering. If you do get output, then you know the server is fine, and the issue lies deeper in your script, in which case you can move the exit()call down a few lines, rinse and repeat. Not an elegant way to debug, but it's quick and dirty, and you'll probably find the issue in a couple of minutes.
在这种情况下，穷人的调试方法可以产生一些快速的结果。将 an exit('wtf');in 作为相关脚本中的第一行。那运行吗？无论结果如何，该测试的结果立即排除了各种可能性。如果你没有得到任何输出，那么它可能是一个服务器级别的问题（配置、坏模块等），但要小心任何更高级别的缓冲。如果确实得到了输出，那么您就知道服务器很好，并且问题出在脚本的更深处，在这种情况下，您可以将exit()调用向下移动几行，冲洗并重复。这不是一种优雅的调试方式，但它快速而肮脏，您可能会在几分钟内找到问题。
回答by txyoji
You could have a .htaccess file in this directory which has modified error reporting.
您可以在此目录中有一个 .htaccess 文件，该文件已修改错误报告。
To test, try explicitly setting these options at the top of your php script which is giving you trouble.
要进行测试，请尝试在 php 脚本的顶部显式设置这些选项，这会给您带来麻烦。
ini_set('display_errors',1);
error_reporting(E_ALL);
I've also seen this caused by over-zealous anti-virus packages. Some contain web proxy software to filter internet and email. In that case, the page would just continue load into infinity but never complete.
我也看到这是由过度热情的防病毒软件包引起的。有些包含网络代理软件来过滤互联网和电子邮件。在这种情况下，页面将继续加载到无穷大，但永远不会完成。
回答by Don Neufeld
Beware the @ (error suppression) operator, if you have a syntax error on a line with @ PHP will silently exit.
当心@（错误抑制）操作符，如果你在一行中出现语法错误@PHP 将静默退出。
To detect this condition, use set_error_handlerand write your own error handler, you'll still get called for errors where @ is used.
要检测这种情况，请使用set_error_handler并编写您自己的错误处理程序，您仍然会在使用 @ 的地方被调用错误。
回答by Jean-Pierre Schnyder
To activate error display in your PHP code in case you don't see anything, insert
要在您的 PHP 代码中激活错误显示以防您看不到任何内容，请插入
ini_set('display_errors',1);
error_reporting(E_ALL);
Example where this potentialy saves you a lot of time:
这个潜力可以为您节省大量时间的示例：
This code in a joomla default.php template file displays a blank page with no error msg without lines 20 and 21
joomla default.php 模板文件中的这段代码显示一个空白页面，没有错误消息，没有第 20 和 21 行
17 <?php if ($params->get('title_article_linkable')) { ?>
18 <a href="<?php
19 $url = JRoute::_(ContentHelperRoute::getArticleRoute($item->id,$item->catid));
20 ini_set('display_errors',1);
21 error_reporting(E_ALL);
22 echo $url; ?>">
23 <?php echo $this->item->title; ?></a> // should be $item->title !!
24 <?phpLL000000 } else { ?>
25 <?php echo $item->title; ?>
26 <?php } ?>
Output:
输出：
回答by Asif
Check php.ini setting for short_open_tag = On or short_open_tag = Off
检查 php.ini 中的 short_open_tag = On 或 short_open_tag = Off 设置
回答by Eric Coleman
The most likely thing here is that apache is crashing. Look through the apache error log maybe, or attach a debugger.
这里最有可能的事情是 apache 崩溃了。查看 apache 错误日志，或者附加调试器。
Details on looking debugging the apache/php process on windows can be found at http://bugs.php.net/bugs-generating-backtrace-win32.php
有关在 Windows 上调试 apache/php 进程的详细信息，请访问http://bugs.php.net/bugs-generating-backtrace-win32.php
回答by SamGoody
When this happens, it is usually worth cutting out as much as possible of the code and seeing if you can get something on the page to show.
发生这种情况时，通常值得尽可能多地删除代码，看看是否可以在页面上显示一些内容。
It could be due to an unclosed quote somewhere in your code, or an unclosed brace. This might cause the echo statement to be viewed as text or in another function, etc.
这可能是由于代码中某处未闭合的引号或未闭合的大括号造成的。这可能会导致 echo 语句被视为文本或在另一个函数中等。
And, while all errors SHOULD be being reported, I have found that not all errors are actually reported, probably because of ini settings on a shared host that is out of my reach.
而且，虽然应该报告所有错误，但我发现并非所有错误都真正报告了，可能是因为我无法触及的共享主机上的 ini 设置。
Commenting out is not always enough - not sure why not. When this happens, I usually find it to be quickest just to copy the page, and slowly cut and paste sections back in till I find the error, after which I can kick myself for a silly typo.
注释掉并不总是足够的 - 不知道为什么不。发生这种情况时，我通常发现复制页面是最快的，然后慢慢地剪切和粘贴部分，直到找到错误为止，然后我可以为一个愚蠢的错字踢自己。
回答by just somebody
check the Event Log.
检查事件日志。
