PHP produces a completely white page, no errors, logs, or headers._问答_开发者

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.

Firebug reports no headers, ? bytes, and it only takes 163ms to "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 worki开发者_如何学运维ng fine until now.

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.

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 weird code 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!

If I find more I'll post back.

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

You could have a .htaccess file in this directory which has modified error reporting.

To test, try explicitly setting these options at the top of your php script which is giving you trouble.

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.

Beware the @ (error suppression) operator, if you have a syntax error on a line with @ PHP will silently exit.

To detect this condition, use set_error_handler and write your own error handler, you'll still get called for errors where @ is used.

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:

A misplaced exit() statement? You were working on the code, maybe you added a quick exit() 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.

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.

Check php.ini setting for short_open_tag = On or short_open_tag = Off

The most likely thing here is that apache is crashing. Look through the apache error log maybe, or attach a debugger.

Details on looking debugging the apache/php process on windows can be found at http://bugs.php.net/bugs-generating-backtrace-win32.php

I guessed the answer to this problem - it turns out that PHP 5.2.5 can't handle a recursive death.

<?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.

To activate error display in your PHP code in case you don't see anything, insert

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

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:

PHP produces a completely white page, no errors, logs, or headers.

check the Event Log.

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.

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.

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.

I had the same problem because I was using:

ob_flush()

did you check your files for closing ?> tags? Or more importantly any whitespace after them...