base18 2

Отладка программ

Отладка (поиск и устранение ошибок) представляет собой неотъемлемую часть разработки программного обеспечения. Программист, работающий на языке PHP, должен быть знаком со всеми доступными инструментальными средствами, позволяющими выявлять неправильно функционирующие компоненты в программных системах.

Количество инструментальных средств отладки достаточно велико. Не в последнюю очередь такая ситуация объясняется тем, что в приложениях PHP обычно используются возможности нескольких серверов (таких как сервер HTTP и сервер, входящий в состав системы управления базами данных), а в комплект каждого из таких серверов обычно входят собственные компоненты ведения журналов и формирования сообщений об ошибках, с помощью которых эти серверы предоставляют своим пользователям возможность следить за происходящим.

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

Кроме встроенных средств формирования сообщений об ошибках языка PHP и технологий, поддерживаемых этим языком, программисты, работающие на языке PHP, в последнее время получили возможность использовать такие же разновидности инструментальных средств отладки, которые в течение многих лет находились в распоряжении программистов, работающих на других языках. Основной среди этих инструментальных средств является среда отладки Zend, которая позволяет контролировать значения переменных, устанавливать точки прерывания и обеспечивать пошаговое выполнение программ с любой желаемой скоростью. В этой статье среда отладки Zend не рассматривается, но ее описание и другие дополнительные сведения можно найти по адресу www.zend.com.

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

Общие стратегии поиска неисправностей

Двумя основными составляющими всей деятельности по отладке являются обнаружение причин нарушения в работе и последующее их устранение (без нарушения функционирования чего-либо иного под воздействием побочных эффектов реализации принятого решения). Это утверждение остается справедливым независимо от того, осуществляется ли диагностика программы PHP, телефонного коммутатора, электронной схемы или автомобиля "Копейка", — определенные принципы остаются в силе, о какой бы рассматриваемой проблемной области не шла речь. Всегда руководствуйтесь таким подходом, пытаясь выяснить, в чем причина нарушений в работе рассматриваемого программного обеспечения.

Внесение изменений только в одном месте

При проведении любых экспериментов необходимо руководствоваться основным правилом: если функционирование рассматриваемого объекта зависит от многочисленных факторов, то невозможно заранее узнать со всей определенностью, чем вызван какой-то конкретный сбой. Поэтому всегда следует вносить только одно изменение, затем проверять полученные результаты и определять, удалось ли устранить нежелательное поведение объекта. В случае отрицательного ответа необходимо внести еще одно изменение (возможно, полностью отменив внесенное перед этим изменение).

Ограничение области проявления проблемы

Если удастся свести поиск причин проблемы до единственной библиотеки или функции, это можно рассматривать как значительный успех в процессе поиска источника проблемы. Используйте специальные вызовы функций echo() и print_r() для своевременного вывода информации трассировки. Это позволяет определить тот момент, когда возникают изменения, являющиеся причиной нарушения в работе, и в какое время переменные приобретают такие значения, которые не должны были содержать.

Кроме того, для контроля над функционированием программ и за поведением компонентов программ в ходе их функционирования можно использовать отладчик с графическим интерфейсом (такой как Zend Studio).

Упрощение и последующее усложнение

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

Документирование принятых решений

Такая ситуация встречается слишком часто: программист часами отыскивает причину ошибки (или даже откладывает эту работу на следующий день) и наконец находит решение. Не следует после этого сразу же отправляться праздновать победу. Найдите время, чтобы отразить в комментариях к программе то, в чем состояла ошибка и каковым является решение. Это позволит вам быть во всеоружии, если снова возникнет та же проблема, а она непременно возникнет.

Повторная проверка после исправления ошибок

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

Общая классификация ошибок

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

Ошибки на этапе компиляции

Язык PHP является компилируемым, но компиляция программы осуществляется непосредственно перед ее выполнением, поэтому сам процесс компиляции не столь очевиден, как в языке C или Java.

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

Ошибки этапа выполнения

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

Логические ошибки

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

Предположим, перед программистом поставлена задача обеспечить запуск космического зонда и вывести его на орбиту вокруг Марса. Программист из США предусмотрел в своем навигационном алгоритме получение входных данных в фунтах и дюймах, но требуемые данные поступают из европейского центра управления полетами в метрической системе. Очевидно, что при таких условиях космический зонд непременно врежется в марсианскую поверхность. Программное обеспечение действовало в полном соответствии с заданием, но, строго говоря, при таких условиях задание предусматривало вывод ракеты прямо на Марс. Это — логическая ошибка.

Из этого следует, что необходимо добиться того, чтобы программа не просто вырабатывала выходные данные, но вырабатывала их правильно. Воспользуйтесь отдельно взятой процедурой расчетов и убедитесь в том, что формируемые программой результаты являются правильными; еще один вариант состоит в том, что результаты программы должны сравниваться с заведомо известными правильными значениями. А для того чтобы не попадать в неприятную историю, не пишите программы на языке PHP для космических кораблей ;).

Использование журналов веб-сервера

Эксплуатация большинства программ PHP приводит к получению HTML-страниц того или иного рода, а эти страницы, в свою очередь, передаются пользователю с помощью HTTP-сервера, такого как Apache или Microsoft Internet Information Server (IIS). Это означает, что дополнительным источником ошибок может стать программное обеспечение веб-сервера. По этой причине важно знать, какой способ применяется в веб-сервере для формирования и регистрации сообщений об ошибках, а также знать о том, как получить доступ и провести синтаксический анализ журналов, в которых регистрируются ошибки.

Сервер Apache

На HTTP-сервере Apache ведутся два файла журнала в формате открытого текста. Эти журналы описаны ниже:

Apache/logs/access.log

Предназначен для регистрации каждого запроса на получение файла, передаваемого по протоколу HTTP. К регистрируемым данным относятся дата, время и полученные результаты (успешное или неудачное завершение, о чем можно судить по числовому коду состояния). Этот журнал представляет собой также журнал регистрации доступа, в котором фиксируется IP-адрес, из которого поступил каждый запрос.

Apache/logs/error.log

Это — журнал регистрации ошибок, в котором фиксируются только ситуации, связанные с возникновением ошибок.

Унифицированный формат журнала

По умолчанию для оформления записей в файле error.log сервера Apache используется унифицированный формат журнала, который принят в качестве стандартного. В этом формате каждая запись соответствует отдельному экземпляру действия, касающегося запроса и/или ответа (в конечном итоге HTTP-серверы занимаются обработкой именно запросов и ответов). Например, одна строка журнала может соответствовать запросу на получение HTML-страницы (и содержать сведения о том, в каких обстоятельствах эта страница была впоследствии предоставлена сервером Apache). А следующая строка может описывать (автоматическое) выполнение запроса и передачу файла JPEG, связанного с ранее затребованным документом HTML.

В любом случае записи в унифицированном формате журнала выглядят примерно так, как показано ниже (в действительности каждая запись занимает только одну строку):

127.0.0.1 - - [12/Jan/2013:03:18:33 +0800] "GET /images/lang.gif HTTP/1.1" 200 6590

Ниже перечислены наиболее важные компоненты данной строки:

  • 127.0.0.1. IP-адрес клиента, от которого поступил запрос по протоколу HTTP (в данном случае локальный хост).

  • [12/Jan/2013:03:18:33 +0400]. Дата, время и разница между временем текущего часового пояса и всеобщим скоординированным временем (Universal Coordinated Time — UTC).

  • GET. Тип запроса HTTP — GET или POST.

  • /images/lang.gif. Затребованный файл.

  • HTTP/1.1. Версия протокола HTTP, используемого для передачи запроса.

  • 200. Код ответа, описывающий результат запроса (дополнительная информация на эту тему приведена ниже в данном разделе).

  • 6590. Количество байтов, переданных в ответе HTTP, соответствующем этому запросу.

Коды ответов HTTP

Количество кодов ответов HTTP весьма велико (хотя самым знаменитым остается код сообщения об ошибке "404 Not Found"), но сами эти коды подчиняются общему шаблону, с помощью которого можно быстро узнать назначение каждого кода. По существу, данные шаблоны подразделяются на категории, описанные ниже:

  • Коды ряда 200 указывают на успешное завершение.

  • Коды ряда 300 обозначают перенаправление.

  • Коды ряда 400 указывают на клиентскую ошибку (подобную указанию в запросе несуществующего документа).

  • Коды ряда 500 указывают на серверную ошибку.

Полный список кодов ответов HTTP приведен по адресу www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.

Сервер IIS

В HTTP-сервере IIS компании Microsoft задача ведения журнала осуществляется иначе. Сервер IIS не записывает журнал в файл, а регистрирует полученную им информацию о состоянии и об обнаруженных ошибках таким образом, чтобы эта информация была доступна для исследования в программе Event Viewer. Ошибки, зарегистрированные сервером IIS, можно найти в части System Log окна Event Viewer, где для обозначения источника применяется имя W3SVC.

Средства формирования сообщений об ошибках и ведения журнала интерпретатора PHP

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

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

Формирование сообщений об ошибках

Выполняемая интерпретатором PHP операция включения сообщения об ошибке в вывод программы (что чаще всего приводит к отображению сообщения об ошибке в окне браузера) по существу представляет собой операцию формирования сообщения об ошибке. Формирование сообщений об ошибках является полезным диагностическим инструментальным средством, использование которого разрешено по умолчанию. Если же интерпретатор PHP подключен к серверу производственного назначения, то данное средство должно быть запрещено.

Чтобы разрешить или запретить формирование сообщений об ошибках, необходимо внести изменение в файл php.ini. При этом корректировка применяется к параметру display_errors. Если требуется, чтобы сообщения выводились в составе формируемых выходных данных, то в файле php.ini должна присутствовать следующая строка:

display_errors=On

Если же сообщения об ошибках не должны отображаться (и это действительно не допустимо, если сервер используется для предоставления к нему общего доступа), то соответствующая строка должна выглядеть таким образом:

display_errors=Off

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

Регистрация ошибок

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

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

log_errors=On

В противном случае следует задать такую опцию:

log_errors=Off

По умолчанию средства регистрации ошибок запрещены в файле php.ini.

Определение категории ошибок, подлежащих выводу на экран или записи в журнал

Принимая решение об использовании средств формирования сообщений об ошибках (для вывода на экран) или средств регистрации ошибок (для записи в файл), необходимо дополнительно указать, какие ошибки рассматриваются как достаточно серьезные для предоставления информации о них пользователю. Параметры настройки средств ведения журнала задаются в файле php.ini с помощью значения параметра error_reporting. По умолчанию параметру error_reporting присваивается следующее значение:

error_reporting=E_ALL & ~E_NOTICE

Такая настройка указывает, что пользователю должна предоставляться информация обо всех ошибках и предупреждениях (что показывает параметр E_ALL), но вместе с тем действует условие (что показывает оператор &), согласно которому извещения этапа прогона не подлежат выводу (для этого служит параметр ~E_NOTICE, где ~ представляет собой оператор отрицания).

Степень серьезности отображаемых сообщений об ошибках, которая определена параметром error_reporting, отражается на поведении средств регистрации ошибок (если их использование разрешено с помощью параметра log_errors=On) и средств формирования сообщений об ошибках (если их использование разрешено с помощью параметра display_errors=On) или одновременно тех и других средств, если все они разрешены.

Функции формирования сообщений об ошибках

Язык PHP не только в значительной степени упрощает работу программистов, но и включает в себя широкий набор функций, которые могут использоваться программистами для облегчения поиска причин нарушений в работе и в целом для получения сведений обо всех аспектах состояния разрабатываемых ими программ. Спектр таких средств начинается с обычных операторов формирования вывода (print, echo и тому подобных), используемых в тех контекстах, когда требуется контролировать значения переменных, и заканчивается специализированными функциями, осуществляющими вывод данных с помощью механизмов ведения журналов операционной системы.

В настоящем разделе даны вводные сведения о некоторых функциях PHP, которые позволяют выявлять причины проблем и создавать отчеты об условиях функционирования программ.

Диагностические операторы вывода

Простейший метод устранения нарушений в работе предусматривает размещение в ключевых местах кода операторов echo и print, для того чтобы формируемые выходные данные содержали информацию о ходе выполнения программы, осуществляемого на основе вызова различных функций, а также о том, какие значения принимают наиболее важные переменные в различных точках.

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

Использование функции var_dump()

Обычные функции вывода являются довольно удобными, но с точки зрения отладки более специализированные функции может оказаться гораздо полезнее. Наиболее важной среди функций подобного типа является функция var_dump(). Она может рассматриваться как чрезвычайно "остроумный" оператор вывода, который, кроме всего прочего, автоматически представляет содержимое любого массива в таком виде, который очень удобен для восприятия человеком.

Напомним, что выполнение приведенного ниже кода приводит к получению результатов, от которых мало пользы:

Код PHP
$fruit = array('orange' => 'Апельсин',
			   'red' => 'Яблоко',
			   'yellow' => 'Банан',
			   'green' => 'Груша');
echo $fruit;

Данные результаты сводятся к следующему:

Использование конструкции echo для вывода массива

Это нам ничего не дает. С другой стороны, если за определением того же массива следует строка

Код PHP
var_dump($fruit);

то формируется следующие намного более полезные выходные данные:

Использование функции var_dump() для вывода массива

На основании таких данных программист, занимающийся отладкой, может немедленно определить, каково содержимое данного массива (чему равны ключи и значения элементов этого массива).

Использование функции syslog()

В языке PHP предусмотрена функция syslog(), которая позволяет осуществлять запись непосредственно в журнал операционной системы, под управлением которой функционирует среда PHP. Это удобная функция, которая становится особенно полезной, если требуется регистрировать всю информацию о проблемах, возникающих в системе, с помощью стандартных средств, или есть необходимость предупредить о нарушении в работе системного администратора, если он непосредственно не соприкасается с разработками на языке PHP.

В целом функция syslog() позволяет указать степень серьезности, связанную с регистрируемым событием, а также ввести сообщение, которое описывает это событие. Затем указанные значения могут быть выведены в журнал для использования в качестве вспомогательной информации для диагностики.

Все возможные опции определения степени серьезности функции syslog() показаны в следующем коде:

Код PHP
$logOptions = array(LOG_DEBUG, LOG_INFO, LOG_NOTICE, LOG_WARNING,
                LOG_ERR, LOG_CRIT, LOG_ALERT, LOG_EMERG);
				
$msg = array('Сообщение отладки', 'Информация', 'Уведомление', 'Предупреждение', 
                'Ошибка', 'Критическая ошибка', 'Серьезная ошибка', 'Кабздец');

foreach($logOptions as $key => $value) {
	syslog($value, $msg[$key]);
}

В системе Microsoft Windows первые три из этих сообщений об ошибках (от LOG_DEBUG до LOG_NOTICE) рассматриваются как информационные, четвертое и пятое считаются предупреждающими, а последние три отмечаются в программе Event Viewer как относящиеся к категории Alerts. Все эти сообщения отображаются со значением источника c-client, которое соответствует одному из вспомогательных процессов сервера Apache:

Сообщения об ошибках с различными степенями серьезности в программе Event Viewer

Использование функции error_log()

Функция error_log() может использоваться для передачи сообщения об ошибке почти в любое место назначения, включая адрес электронной почты. Эта функция предоставляет легкий и удобный способ формирования отчета о непредвиденных условиях, возникших в процессе функционирования программного обеспечения PHP, но, к сожалению, этим средством пользуются лишь немногие разработчики. Более подробно она описана в предыдущей статье в разделе "Ведение журнала и отладка".

Нарушения в работе системы PHP
Безопасность

Комментарии (0)

Результаты поиска по запросу

Система Orphus