PHP создает полностью белую страницу, без ошибок, логов или заголовков.

Question

При запуске некоторого кода PHP на моем частном ПК WAMP я неожиданно получаю пустой ответ от сервера - на самом деле никакого ответа. Нет заголовков, нет данных, ничего в логах ошибок PHP, нада. Я перезапустил APACHE и PHP, но все еще ничего. Я знаю, что php работает, потому что я могу нормально обращаться к другим PHP-скриптам.

Firebug не сообщает заголовков, байт, и для «загрузки» требуется только 163 мс (так что это не тайм-аут). Я думал о быстром потреблении памяти - но я контролировал память моего ПК, и она не показала скачков. Ошибки и исключения до сих пор работали нормально.

Что в мире?

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:

Я бы не трогал @ шестисотом. Я думаю, что ребята из Ruby добавили это туда, чтобы программисты сбросили PHP.

В любом случае, я включил xdebug, и он не выводил никаких файлов измельчения. Затем я воспользовался советом зомбата и поместил DIE () в верхней части страницы, и это сработало. Я думаю, что у меня просто есть какой-то очень странный код, который полностью убивает PHP. Даже если ошибки были отключены или подавлены с помощью @, я все равно должен получить заголовок с сервера с пустым содержимым!

Если я найду больше, я отправлю ответ.

Answer 1

Запустите страницу из консоли, и вы получите сообщение об ошибке.

// nix
php yourFile.php

// Windows
c:\path\to\php.exe yourFile.php

Answer 2

Вы говорите, что другие PHP-скрипты работают, что указывает на то, что это, вероятно, не проблема Apache. Вы также, кажется, правильно настроили все свои параметры ведения журнала, и ничего не регистрируется, поэтому вполне возможно, что PHP нормально завершает работу, прежде чем что-либо выводит. Может быть верно одно из следующих действий:

• Неуместное exit() заявление? Вы работали над кодом, может быть, вы добавили быстрый exit(), чтобы проверить что-то, и забыли удалить его?
• Идея don.neufeld о проверке использования оператора @, который подавляет любые сообщения об ошибках, в прошлом стоила мне часов отладки. Определенно что-то искать.

В подобных ситуациях подход отладки бедняка может дать некоторые быстрые результаты. Добавьте сюда exit('wtf'); в качестве первой строки в рассматриваемом скрипте. Это работает? Результаты этого теста немедленно исключают всевозможные возможности, независимо от того, каков результат. Если вы не получите никакого вывода, то это, вероятно, проблема на уровне сервера (конфигурация, неисправный модуль и т. Д.), Хотя будьте осторожны с буферизацией более высокого уровня. Если вы получаете вывод, то вы знаете, что с сервером все в порядке, и проблема кроется в вашем скрипте, и в этом случае вы можете переместить вызов exit() на несколько строк, промыть и повторить. Не элегантный способ отладки, но он быстрый и грязный, и вы, вероятно, найдете проблему через пару минут.

Answer 3

Остерегайтесь оператора @ (подавление ошибок), если у вас есть синтаксическая ошибка в строке с @ PHP, она молча завершится.

Чтобы обнаружить это условие, используйте set_error_handler и напишите свой собственный обработчик ошибок, вы все равно будете вызывать ошибки, где используется @.

Answer 4

В этом каталоге может быть файл .htaccess, который изменил сообщение об ошибке.

Чтобы проверить, попробуйте явно установить эти параметры в верхней части вашего PHP-скрипта, который доставляет вам проблемы.

ini_set('display_errors',1);
error_reporting(E_ALL);

Я также видел, что это вызвано чрезмерным усердием антивирусных пакетов. Некоторые содержат программное обеспечение для веб-прокси для фильтрации Интернета и электронной почты. В этом случае страница просто продолжит загрузку в бесконечность, но никогда не завершится.

Answer 5

Чтобы активировать отображение ошибок в вашем PHP-коде, если вы ничего не видите, вставьте

ini_set('display_errors',1); 
error_reporting(E_ALL);

Пример, где этот потенциал экономит много времени:

Этот код в файле шаблона 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 } ?>

Выход:

Answer 6

Я угадал ответ на эту проблему - оказывается, что 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';

Нет заголовков, ошибок, содержимого, журналов, дампов xdebug, скачков памяти, скачков ЦП, сбоев сервера или чего-либо еще. Примерно через 150 мс PHP просто «заканчивается». Weird.

Answer 7

Скорее всего, здесь происходит сбой apache. Посмотрите журнал ошибок apache или прикрепите отладчик.

Подробную информацию об отладке процесса apache / php в Windows можно найти по адресу http://bugs.php.net/bugs-generating-backtrace-win32.php

Answer 8

Проверьте настройку php.ini для short_open_tag = On или short_open_tag = Off

Answer 9

Когда это происходит, обычно стоит вырезать как можно больше кода и посмотреть, сможете ли вы получить что-то на странице, чтобы показать.

Это может произойти из-за незакрытой цитаты где-то в вашем коде или нераскрытой скобки. Это может привести к тому, что оператор echo будет рассматриваться как текст или другая функция и т. Д.

И, хотя обо всех ошибках следует сообщать, я обнаружил, что на самом деле сообщается не обо всех ошибках, возможно, из-за настроек ini на общем хосте, который мне недоступен.

Комментирование не всегда достаточно - не уверен, почему нет. Когда это происходит, я обычно нахожу, что быстрее всего просто скопировать страницу и медленно вырезать и вставлять разделы обратно, пока не найду ошибку, после чего я могу пнуть себя за глупую опечатку.

Answer 10

проверьте журнал событий.