PHP создает полностью белую страницу, без ошибок, журналов или заголовков.
при запуске некоторого PHP-кода на моем частном компьютере WAMP я внезапно получаю пустой ответ от сервера-на самом деле нет ответа. Нет заголовков, нет данных, ничего в журналах ошибок PHP, nada. Я перезапустил APACHE и PHP, но все равно ничего. Я знаю, что php работает, потому что я могу получить доступ к другим скриптам PHP просто отлично.
Firebug сообщает нет заголовков,? байты, и это занимает только 163ms для "загрузки" (так что это не тайм-аут). Я думал о быстром потреблении памяти - но я контролировал память моего компьютера, и он не показывает никаких шипов. До сих пор ошибки и исключения работали нормально.
что в мире?
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, и он не выводил никаких файлов grind. Затем я последовал совету зомбата и поместил DIE() в верхней части страницы, и это сработало. Я думаю что у меня есть очень странно код, который полностью убивает PHP. Даже если ошибки были отключены или подавлены с помощью @ Я все равно должен вернуть заголовок с сервера с пустым содержимым!
Если я найду больше, я отправлю обратно.
11 ответов
запустите страницу с консоли, и вы получите сообщение об ошибке.
// nix
php yourFile.php
// Windows
c:\path\to\php.exe yourFile.php
вы могли бы иметь .файл htaccess в этом каталоге, который изменил отчеты об ошибках.
чтобы проверить, попробуйте явно установить эти параметры в верхней части вашего PHP-скрипт, который дает вам неприятности.
ini_set('display_errors',1);
error_reporting(E_ALL);
Я также видел это, вызванное чрезмерным усердием антивирусных пакетов. Некоторые содержат программное обеспечение веб-прокси для фильтрации интернета и электронной почты. В этом случае страница просто продолжит загрузку в бесконечность, но никогда не будет завершена.
остерегайтесь оператора @ (подавление ошибок), если у вас есть синтаксическая ошибка в строке с @ PHP будет тихо выйти.
для того чтобы обнаружить это условие, используйте set_error_handler и напишите свой собственный обработчик ошибок, вы все равно будете вызывать ошибки, где используется@.
вы говорите, что другие скрипты PHP работают, так что это указывает на то, что это, вероятно, не проблема Apache. Вы также, кажется, все ваши настройки ведения журнала правильные, и ничего не регистрируется, поэтому вполне возможно, что PHP выходит нормально, прежде чем он выводит что-либо. Одно из следующих предположений может быть верным:--6-->
- странник
exit()заявление? Вы работали над кодом, возможно, вы добавили quickexit()чтобы проверить что-то, и забыл удалить это? - нет.идея нойфельда о проверке использования
@оператор, который подавляет любые сообщения об ошибках, стоил мне часов времени отладки в прошлом. Определенно есть на что посмотреть.
в таких ситуациях, как эта, подход отладки бедного человека может дать некоторые быстрые результаты. Бросьте exit('wtf'); в качестве первой строки в рассматриваемом скрипте здесь. Это работает? Результаты этого теста сразу исключает всякие возможности ни каков результат. Если вы не получаете никакого вывода, то это, вероятно, проблема уровня сервера (конфигурация, плохой модуль и т. д.), Хотя будьте осторожны с буферизацией более высокого уровня. Если вы получаете вывод, то вы знаете, что сервер в порядке, и проблема лежит глубже в вашем скрипте, и в этом случае вы можете переместить exit() вызовите несколько строк, промойте и повторите. Не элегантный способ отладки, но он быстрый и грязный, и вы, вероятно, найдете проблему через пару минут.
наиболее вероятно, что apache рушится. Возможно, просмотрите журнал ошибок apache или присоедините отладчик.
подробности о поиске отладки процесса apache / php в windows можно найти по адресуhttp://bugs.php.net/bugs-generating-backtrace-win32.php
Я угадал ответ на эту проблему-оказывается, 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, всплесков памяти, всплесков процессора, сбоев сервера или чего-либо еще. Примерно через 150ms PHP просто "заканчивается". Странный.
чтобы активировать отображение ошибок в PHP-коде, если вы ничего не видите, вставьте
ini_set('display_errors',1);
error_reporting(E_ALL);
пример, где этот потенциал экономит вам много времени:
этот код в Joomla по умолчанию.файл шаблона php отображает пустую страницу без ошибок msg без строк 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 } ?>
выход:
когда это происходит, обычно стоит вырезать как можно больше кода и посмотреть, можете ли вы получить что-то на странице, чтобы показать.
Это может быть связано с незамкнутой цитатой где-то в вашем коде или незамкнутой скобкой. Это может привести к тому, что оператор echo будет рассматриваться как текст или в другой функции и т. д.
и, хотя все ошибки должны сообщаться, я обнаружил, что не все ошибки фактически сообщаются, вероятно, из-за настроек ini на общий узел, который находится вне моей досягаемости.
комментирования не всегда достаточно - не уверен, почему нет. Когда это происходит, я обычно быстрее всего копирую страницу, медленно вырезаю и вставляю разделы обратно, пока не найду ошибку, после чего могу пнуть себя за глупую опечатку.