PHP производит абсолютно белую страницу, никакие ошибки, журналы или заголовки.
В то время как выполнение некоторого PHP кодирует на моем частном ПК WAMP, я внезапно получаю пустой ответ от сервера - никакой ответ на самом деле. Никакие заголовки, никакие данные, ничто в журналах ошибок PHP, nada. Я перезапустил 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:
Я не затронул бы @ полюсными десятью футами. Я думаю, что рубиновые парни бросают это там, таким образом, программисты отбросили бы PHP.
Так или иначе я включил xdebug, и он не производил, любой шлифует файлы. Затем я послушал совет zombat и поместил УМИРАНИЕ () в верхней части страницы, и он работал. Я предполагаю, что у меня просто есть некоторый очень странный код, который полностью уничтожает PHP. Даже если ошибки были отключены или подавлены с @ Я должен все еще возвращать заголовок с сервера с пустым содержанием!
Если я нахожу больше, что я отправлю назад.
10 ответов
Я угадал ответ на эту проблему - оказалось, что 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 просто "заканчивается". Странно.
В этом каталоге может быть файл .htaccess, который изменил сообщения об ошибках.
Чтобы проверить, попробуйте явно установить эти опции в верхней части вашего php-скрипта, что доставит вам неприятности.
ini_set('display_errors',1);
error_reporting(E_ALL);
Я также видел, что это вызвано чрезмерно усердными антивирусными пакетами. Некоторые из них содержат программное обеспечение веб-прокси для фильтрации Интернета и электронной почты. В этом случае, страница будет просто продолжать загружаться до бесконечности, но никогда не будет завершена.
Проверьте настройку php.ini на short_open_tag = Включено или short_open_tag = выключено
.Запустите страницу из консоли, и вы получите сообщение об ошибке.
// nix
php yourFile.php
// Windows
c:\path\to\php.exe yourFile.php
Вы говорите, что другие PHP-скрипты работают, так что это указывает на то, что это, вероятно, не проблема Apache. Вы также считаете, что все ваши настройки протоколирования корректны, и ничего не регистрируется, так что вполне возможно, что PHP выходит из системы нормально, прежде чем что-либо вывести на экран. Один из следующих выводов может быть правдой:
- Неуместное утверждение
exit()? Вы работали над кодом, возможно, вы добавили быстрыйexit()для проверки чего-то и забыли его удалить? Идея don.neufeld проверить использование оператора@, который подавляет любые сообщения об ошибках, в прошлом стоила мне часов отладки. Определенно, на что стоит обратить внимание.
В подобных ситуациях отладочный подход бедняка может дать быстрый результат. Бросьте здесь exit('wtf'); в качестве первой строки в рассматриваемом скрипте. Это выполняется? Результаты этого теста сразу же исключают всевозможные возможности вне зависимости от результата. Если вы не получите никакого результата, то, скорее всего, это проблема на уровне сервера (конфигурация, плохой модуль и т.д.), хотя будьте осторожны с любой буферизацией более высокого уровня. Если вы все-таки получите вывод, то вы знаете, что сервер в порядке, и проблема лежит глубже в вашем скрипте, и в этом случае вы можете переместить вызов exit() вниз на несколько строк, прополоскать и повторить. Не элегантный способ отладки, но он быстрый и грязный, и вы, вероятно, найдете проблему через пару минут.
Остерегайтесь оператора @ (подавление ошибок), если у вас синтаксическая ошибка на строке с @ PHP будет бесшумно завершаться.
Для обнаружения этого условия используйте set_error_handler и напишите свой обработчик ошибок, вы все равно получите вызов обработчика ошибок, где используется @.
.Наиболее вероятная вещь здесь - это то, что апач рушится. Возможно, вы просмотрите журнал ошибок apache или прикрепите отладчик.
Подробная информация об отладке процесса apache/php в окнах находится по адресу http://bugs.php.net/bugs-generating-backtrace-win32.php
Вы проверяли свои файлы на закрытие тегов ?>? Или, что более важно, любые пробелы после них...
Когда такое случается, обычно стоит вырезать как можно больше кода и посмотреть, можно ли что-нибудь показать на странице.
Это может быть из-за незакрытой цитаты где-то в вашем коде, или из-за незакрытой скобки. Это может привести к тому, что эхо-выражение будет выглядеть как текст или в другой функции и т.д.
И пока обо всех ошибках сообщается, я обнаружил, что на самом деле не обо всех ошибках сообщается, вероятно, из-за настроек ini на общем хосте, которые мне недоступны.
Комментариев не всегда достаточно - не уверен, почему бы и нет. Когда это происходит, я обычно считаю, что быстрее всего просто скопировать страницу, и медленно вырезать и вставить секции обратно до тех пор, пока не найду ошибку, после чего могу пнуть себя за дурацкую опечатку.