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


Содержание

Как найти ошибку в своем коде?

Быстрые рекомендации.
1. Убедитесь, что вы видите сообщения об ошибках, если они возникают.
Для этого надо добавить в начало скрипта 2 строчки
ini_set ( ‘display_errors’ , 1 );
error_reporting ( E_ALL );
Хотя в некоторых случаях это всё равно не поможет. Тогда смотрите ошибки в логах веб-сервера.
Ещё можно добавить в файл .htaccess строчку
php_flag display_errors 1
Обязательно убрать всех собак (@) из кода!
Если апач выдаёт ошибку 500 — значит надо смотреть текст ошибки в логе ошибок веб-сервера.

2. Если возникают проблемы с функциями MySQL (например «supplied argument is not a valid MySQL result resource») — это значит, что mysql_query() выполнилась с ошибкой. Чтобы всегда быть в курсе таких ошибок, функцию mysql_query надо вызывать так:

$sql = «SELECT * FROM table» ;
$res = mysql_query ( $sql ) or trigger_error ( mysql_error (). » in » . $sql );

Если используется mysqli, то перед коннектом написать 1 строчку:
mysqli_report ( MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT );

Если используется PDO, то соединяться, как написано здесь: http://phpfaq.ru/pdo#connect

3. При работе с изображениями, чтобы увидеть сообщение об ошибке, обязательно надо догадаться отключить вывод заголовка, говорящего браузеру, что дальше идет картинка.
И, естественно, обращаться к скрипту напрямую, а не через тег !

4. При проблемах в аплоаде в первую очередь смотрите массив $_FILES ( print_r ( $_FILES ); ). Описания ошибок из $_FILES[‘filename’][‘error’] есть в мануале.

5. При проблемах во взаимодействии сервера и клиента (куки, сессии, запросы)- в обязательном порядке смотреть обмен HTTP заголовками

6. Закомментируйте строчку с header(«Location:»), если ищете обшибку в обработчике POST запроса

7. При отладке AJAX запросов смотрите ответ сервера в FireBug-e и его аналогах (кнопка F12 в любом браузере), вкладка Network — Preview.

8. И САМОЕ ВАЖНОЕ: запуская скрипт, смотрите не то, что показывает браузер, а ИСХОДНЫЙ HTML код!.

Получив сообщение об ошибке, вы можете его прочитать и исправить.
Если не справились — пишите на форум. При этом КОПИРУЙТЕ сообщение об ошибке, и КОПИРУЙТЕ небольшой — 3-5 строк — кусок кода, на который указывает ошибка. Повторяю — КОПИРУЙТЕ! никакой отсебятины!

Если вы всё равно не нашли ошибку — читайте дальше:

Введение. Очень важное.
Ты написал программу, а она не работает.
Вариантов ты видишь немного — либо сидеть и пытаться умственным усилием обнаружить ошибку, в сотый раз просматривая код, либо пойти на форум и попросить, чтобы там тебе нашли ошибку.
Самое интересное, что есть третий, в сто раз лучше первых двух.
Этот способ называется «Отладка программы». По-английски — debug.
Заключается он в том, чтобы заставить программу саму показать, где в ней ошибка.
Это мало того, что получится быстрее, чем спрашивать на стороне — так зачастую это единственный способ решить проблему. Единственный.
Я тебе сейчас открою страшный секрет. В мире НЕТ программистов, которые пишут код, как художники на Арбате — сел, наваял, отдал. Нету. И не будет.
Процесс написания программы — циклический: Написал кусок кода — посмотрел, как работает. Если не работает — ищем ошибки. Работает — пишем дальше.
Только так. Других вариантов нет.
Больше того. В большинстве случаев совершенно бесполезно вываливать на форум свой код, и спрашивать — «В чём ошибка?». На форуме не сидят волшебники вперемешку с телепатами. И гадалок с прорицателями — тоже нет. Поэтому отгадывать, в чём, теоретически, может быть ошибка, никто не будет. Ошибку найти может только хозяин программы. На своём сервере. Со своими настройками и опечатками. Поэтому локализовать ошибку — найти место, где она происходит, определить тип ошибки — можно только самостоятельно. А вот исправить её на форуме помогут. Если не получится самому.

Те, кто приходит к веб-программированию от дизайна, или от игр, или от нечего делать, просто не знают этой страшной тайны: Основное время программиста уходит не на написание кода. Основное время программиста уходит на поиск ошибок и отладку. Это не шутка. Это правда. И если вы решили заняться программированием, то вам придётся искать ошибки точно так же, как это делают все остальные.
К сожалению, очень много людей приходит к PHP вообще без опыта программирования и, как следствие — никогда не слышали об отладке.
А это и есть самое главное в программировании — умение искать ошибки.
И мы с тобой сейчас будем учиться их искать.

Программа не работает. Что можно сделать в этом случае?

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

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

Это чудовищные заблуждения. Сообщения об ошибках — это ПОМОЩЬ! Это громадная помощь программисту. Как ей воспользоваться, мы рассмотрим ниже.

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

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

Во-первых, надо выяснить, выводятся ошибки на экран или пишутся в лог. Обычно, домашний, или тестовый сервер настраивается так, чтобы ошибки выводились на экран. Рабочий же сервер, с сайтом в публичном доступе ОБЯЗАТЕЛЬНО должен быть настроен так, чтобы ошибки не выводились на экран (поскольку посетителю они все равно ничего не скажут, а программист их не увидит), а писались в лог, где программист их увидит.
Если ты не уверен, и не знаешь, где посмотреть, а ошибку найти надо срочно, то напиши в самом начале скрипта две строчки
ini_set ( ‘display_errors’ , 1 );
error_reporting ( E_ALL ^ E_NOTICE );
Эти две строки заставят выводить сообщения обо всех критических ошибках на экран.
Если никаких ошибок не выведется, надо написать
error_reporting ( E_ALL );
Это очень сильно поможет, показав несуществующие переменные и другие мелкие ошибки, которые обычно игнорируются, но от которых может зависеть работоспособность программы.
ВАЖНО! В случае ошибки синтаксиса, по очевидным причинам, установка с помощью ini_set не сработает.
Поэтому лучше на неё не надеяться, а либо исправить в php.ini (или в .haccess добавить строчку php_flag display_errors 1 ), либо искать ошибку в логе.

Во-вторых, убедись, что в коде отсутствуют символы ‘@’ перед именами функций. Этот запрещает вывод сообщения об ошибке. Хорошенькое дело! Ты ошибку ищешь-ищещь, а сам же своей программе рот заткнул.

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

При возникновении проблем с функциями mysql (supplied argument is not a valid MySQL result resource) под строкой, где произошла ошибка, обязательно надо вывести на экран mysql_error() и сам запрос — для визуального контроля и копирования на форум.

При работе с изображениями, чтобы увидеть сообщение об ошибке, обязательно надо догадаться отключить вывод заголовка, говорящего браузеру, что дальше идет картинка.
При аплоаде в первую очередь смотрите массив $_FILES.
При проблемах во взаимодействии сервера и клиента — в обязательном порядке смотреть обмен HTTP заголовками
И всегда смотрите не то, что показывает браузер, а ИСХОДНЫЙ HTML код!

Допустим, сообщение об ошибке появляется, и ты его получил. Что делать дальше? Очень просто — прочесть и исправить. Если не хватает знания английского языка, то стоит либо воспользоваться переводчиком, либо взять значащую часть этого сообщения и запросить Google. 90% вероятности, что кто-то с такой ошибкой уже сталкивался, и ты тут же прочтешь ответ.
Если же не нашел, то задай вопрос в форуме, точно скопировав небольшой (3-5 строк) кусок кода, в котором произошла ошибка, точно указав строку, о которой говорится в сообщении об ошибке, а так же — самое главное! — само сообщение об ошибке.
Согласись, что с такой информацией тебе на форуме помогут гораздо скорее и качественней?

Отладка и поиск ошибок в своем алгоритме.
Но бывает так, что программа не вызывает ошибок, но все равно не работает, или работает не так, как надо.
Тут уже виноват или алгоритм или какие-то внешние факторы.
Однако и тут можно найти место, где происходит ошибка.
Но только при одном условии.
что ты четко представляешь, что делает твоя программа, каждая функция, каждая строка в ней. Потому, что если ты представляешь, то можешь предсказать, какие значения должны иметь переменные на каждом этапе выполнения.
А дальше все ОЧЕНЬ просто!
Во-первых, надо разделить программу на логические блоки.
Допустим, скрипт выводит форму, получает ее, и записывает данные в базу. ТРИ шага! И в любом из них может быть ошибка, приводящая к тому, что данные в базу не записываются.
Надо проконтролировать на каждом из участков — все ли переменные имеют то значение, которое ожидается.
Программа ведь работает с переменными.
Как проверить?
Выводить все используемые переменные на экран! И визуально контролировать их содержимое.
Всего-то лишь написать проблемных местах var_dump($var) и выяснится, что переменная-то пустая!
И уже можешь пойти на форум не с вопросом «у меня вот код на 100 строк, где ошибка?», а «я написал функцию, но почему-то, когда обращаюсь в ней к переменным, они все пустые». или «из формы не передаются переменные».
Между этими двумя способами задания вопросов — пропасть.
Первый не может тебе помочь никак. Ты, собственно, и сам не знаешь, что у тебя за проблема. А при втором ты уже знаешь проблему, и, если сам не справился с ее решением, то можешь задать на форуме конкретный вопрос.

Еще очень поможет избежать ошибок в программе выставление error_reporting в E_ALL с самого начала работы скрипта.
Если при отлове критических ошибок сообщения о потенциальных ошибках могут нам помешать увидеть главную, то при разработке нам желательно видеть все — и потенциальные в том числе. Скажем, при E_ALL, при обращении к несуществующей переменной, PHP выдаст предупреждение. То есть, тебе не придется самому выводить переменную, чтобы выяснить, что ты не присвоил ей никакого значения — РНР тебя сам предупредит.

Пример отладки.
Из html формы передаются чекбоксы с именами c_1, c_1, c_3. c_10
В скрипте мы пытаемся в цикле вывести
for ( $i = 1 , $i 11 , $i ++) <
echo $_POST [ ‘с_$i’ ];
>
скрипт ничего не выводит.
Начинаем отлаживать.
Сначала смотрим в исходный код html страницы. соответствует ли она стандартам?
Допустим, соответствует. Значит, проблема не в форме.
Далее, проверяем в скрипте — а есть ли такая переменная, к которой мы обращаемся — массив $_POST?
пишем

echo ‘

‘ ;
var_dump ( $_POST );

Убеждаемся в том, что массив есть и все элементы на месте. Значит, проблема не в передаче.
Значит, мы как-то неправильно обращаемся к массиву.
обращаемся мы к нему так: $_POST[‘с_$i’]
Надо проверить — а во что превращается ‘с_$i’?
делаем echo ‘с_$i’; и видим. совсем не то, что ожидали увидеть.
И вот теперь уже идем либо читать документацию про строки в пхп (что предпочтительнее), либо — на форум, с вопросом «почему у меня переменная не заместилась своим значением». Каковой вопрос будет гораздо лучше звучать, чем «у меня форма не работает».
Понятно?

Следует понимать, что здесь приведён пример, Нереальный. Показан алгоритм действий.
В реальности, при error_reporting(E_ALL); PHP сразу же показал бы, что индекс массива у вас неправильный.

Самое важное — знать, что ты хочешь получить.
Примерно половина вопросов на форумах вызвана тем, что человек делает что-то. НЕ ЗНАЯ, что именно!
Самый гениальный вопрос всех времён и народов: «у меня база съела все переводы строк из текстарии».
Человек просто не дал себе труд посмотреть, как будет выглядеть HTML, который он хочет получить, и решил, что переводы строк съела база.
И так во всём.
Непризнанный гений строит сложный SQL запрос, а когда его спрашивают, как запрос должен выглядеть — он только хлопает глазами. ВСЕГДА СНАЧАЛА составьте запрос руками и выполните в консоли или phpmyadmin! А после того, как получили нужный запрос и отладили — милости просим, составляйте его на пхп.
Работа с удалённым хостом через сокет по протоколу HTTP — то же самое! Сначала научитесь выполнять все команды руками, посмотрите ответы сервера глазами, а потом моделируйте этот диалог в пхп.
Работа с яваскриптом по тому же методу описана в факе «на танке»

Запомните — на пхп вы работаете только со СТРОКАМИ! HTML страница, которую вы создаёте скриптом — это для пхп всего лишь набор строк! Ему без разницы, что в этом наборе — теги img, script или frame. Пхп за вас не сделает переводы строк, не нарисует яваскрипт. Если вы не знаете яваскрипта — то не пытайтесь создавать программу на нём с помощью PHP.
Открывая соединение с удалённым хостом, вы посылаете строку в сокет, вы получаете строку из сокета. Пхп ничего не понимает в этих строках и за вас диалог вести не будет! Это ВЫ должны чётко понимать, что вы хотите послать в сокет, и что получить! Поэтому возьмите программу telnet, соединитесь с нужным хостом и пробуйте сначала САМИ сделать то, что хотите заставить сделать пхп.
Если у вас не работает скрипт с сокетами — бегом в телнет смотреть, что происходит!
SQL запрос — это СТРОКА. Вы должны себе чётко представлять, какой запрос получится в результате вашего хитроумного пхп-кода! Сервер БД не понимает конструкций intval, date, mktime и так далее! Это всё пхп-код. Результатом которого будет являться строка корректного SQL запроса. прежде, чем писать пхп код, вы должны ЧЁТКО СЕБЕ ПРЕДСТАВЛЯТЬ, КАК ДОЛЖЕН ВЫГЛЯДЕТЬ SQL ЗАПРОС В РЕЗУЛЬТАТЕ!
Если у вас не выполняется SQL запрос 0 выводите его на экран и смотрите — что нагородили своим скриптом!

Заключение.
Отладка — главное занятие программиста.
Отладка — единственный и самый мощный способ найти ошибку в программе.
Отладка состоит из двух основных компонентов:
1. Максимально упрощать пример. Если у вас не работает программа, которая рисует форму,получает данные, записывает данные формы в базу и выводит их снова, то разбейте программу на составляющие и выполняйте по очереди.
Если у вас не работает сложная подпрограмма определения работоспособности кук — напишите сначала тест в две строчки чтобы убедиться, что вы хотя бы можете выставлять и читать куку.
2. Вывод отладочной информации.
Проверяйте значение КАЖДОЙ переменной! Каждого значения, возвращаемого функцией!
Не работает локейшен? Выведите его на экран и скопируйте в браузер!
В файл записывается пустая строка? проверяйте составляющие этой строки на каждом этапе ее создания и выводите на экран!
Убедились, что на экран выводится? Тренируйтесь писать в файл, на тестовой строке! Забитой прямо в скрипт! Уменьшайте количество неизвестных!
И всегда смотрите не то, что показывает браузер, а ИСХОДНЫЙ HTML код!

Надеюсь, что я смог хотя бы немного объяснить принципы этого занятия.
Удачной отладки.

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

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

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

Вывод ошибок делится на две части: непосредственно сообщение с ошибкой и бектрейс. Бектрейс (иногда говорят «стектрейс») — это список всех вызовов функций от запуска программы вплоть до того места, где произошла ошибка. Бектрейс — очень важный инструмент, который позволяет увидеть то, как выполнялась ваша программа, и какие функции вызывались. Отладка всегда сводится к двум вещам: 1) перевести сообщение об ошибке, 2) найти в бектрейсе то место в своем коде, после которого произошла ошибка.

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

Типы ошибок

Наиболее простые и понятные ошибки — синтаксические. Они связаны исключительно с тем, что код записан неверно, например забыта точка с запятой в конце инструкции. В выводе таких ошибок всегда присутствуют фразы parse error и syntax error. Для их исправления нужно открыть то место в коде, на которое указывает ошибка, и внимательно на него посмотреть.

Еще одна большая группа ошибок называется ошибками программирования. К ним, например, относятся:

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

Эти ошибки исправить труднее, чем синтаксические. Обычно они возникают в результате неправильной логики в другом, более раннем вызове.

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

Отладка

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

Рассмотрим конкретный пример. Ниже описана функция, которая считает сумму чисел от числа $start до числа $finish . Если начало равно трем, а конец — пяти, то программа должна вычислить: 3 + 4 + 5 .

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

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

Глядя на код функции sumOfSeries замечаем, что основных переменных там две: $i и $sum , именно они меняются в цикле. Из этого можно сделать ровно один вывод: нужно явно посмотреть, какие значения им даются на каждой итерации. После этого найти ошибку не составит труда.

Илон Маск рекомендует:  Переносы слов

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

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

То что печатается на экран, отображается во вкладке OUTPUT , на которую автоматически переключается редактор во время проверки. Из этого вывода сразу можно понять, что количество итераций цикла меньше чем нужно на одну. Почему-то не выполняется сложение для последнего числа, которое обозначено как $finish . И действительно, если посмотреть на определение, то видно, что там используется $i вместо $i .

Отладочная печать через print_r не очень удобна тем, что эта функция не ставит автоматически перенос строк. К тому же иногда хочется завершить выполнение кода сразу, как только был сделан первый вывод. Для решения этой задачи на Хекслете подключена библиотека var-dumper. Она предоставляет две функции: dump и dd , которые доступны в любом месте программы. Первая просто красиво выводит переданный аргумент, а вторая — еще и останавливает выполнение кода (прямо сейчас эта функция не работает в практиках, но мы исправим этот момент).

Эта функция добавляет в вывод перевод строки, но особенно удобно использовать ее с массивами, которые мы скоро изучим.

Как и какими средствами находить ошибки в PHP коде?

При разработке, порой, код не работает так, как задумано или вообще не работает. Сижу, гадаю: что и где не так?

Час посмотрев на код — иду на проф. ресурсы, например Stack Overflow и публикую вопрос «Где здесь ошибка?» или «Почему не работает?»

В итоге часто проблема мелкая, дурацкая опечатка, ошибка в синтаксисе и прочее. Профессионалом так не станешь, если по каждой ерунде бегать по ресурсам. А я хочу им быть.

Вопрос: какие есть способы, чтобы найти ошибки в PHP коде? Какие инструменты, методы, плагины, пути и пр.?

4 ответа 4

Вчера всё работало, а сегодня не работает / Код не работает как задумано

Debugging (Отладка)

В чем заключается процесс отладки? Что это такое?

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

Будет рассмотрен пример с PHPStorm, но отладить код можно и в любой другой IDE.

Подготовка

Для начала необходимо, чтобы в PHP имелась библиотека для отладки под названием xdebug. Если её еще нет, то надо скачать на xdebug.org.

Обычно все библиотеки лежат в папке ext внутри папки PHP. Туда и надо поместить dll .

Далее в php.ini прописываем настройки:

Перезагружаем сервер, на всякий случай.

Теперь если в файле .php написать phpinfo(); то можно будет увидеть в самом низу такую картину:


  • нажимаем create project from existing files
  • выбираем Web server is installed locally, source files are located under its document root
  • выбираем папку с файлами, и нажав вверху кнопку «Project Root» помечаем папку как корень проекта
  • нажимаем «Next»

нажимаем Add new local server

  • вводим имя сервера любое и Web Server root URL . В рассматриваемом примере это http://localhost/testy2
    • нажимаем «Next» и затем «Finish»

    Запуск

    Для начала в левой части панели с кодом на любой строке можно кликнуть ЛКМ , тем самым поставив точку останова (breakpoint — брейкпойнт). Это то место, где отладчик автоматически остановит выполнение PHP, как только до него дойдёт. Количество breakpoint’ов не ограничено. Можно ставить везде и много.

    Если кликнуть ПКМ и во всплывающем меню выбрать Debug (или в верхнем меню — Run → Debug ), то при первом запуске PHPStorm попросит настроить интерпретатор. Т.е. надо выбрать версию PHP из папки, где он лежит, чтобы шторм знал, какую версию он будет отлаживать.

    Теперь можно нажать Debug .

    В данном случае, т.к. функция вызывается сразу на той же странице, то при нажатии кнопки Debug — отладчик моментально вызовет функцию, выполнение «заморозится» на первом же брейкпойнте. В ином случае, для активации требуется исполнить действие, при котором произойдет исполнение нужного участка кода (клик на кнопку, передача POST-запроса с формы с данными и другие действия).

    1. Стэк вызовов, все вложенные вызовы, которые привели к текущему месту кода.
    2. Переменные. На текущий момент строки ниже номера 3 ещё не выполнились, поэтому определена лишь $data
    3. Показывает текущие значения любых переменных и выражений. В любой момент здесь можно нажать на + , вписать имя любой переменной и посмотреть её значение в реальном времени. Например: $data или $nums[0] , а можно и $nums[i] и item[‘test’][‘data’][$name[5]][$info[$key[1]]] и т.д. На текущий момент строки ниже номера 3 ещё не выполнились, поэтому $sum и $output обозначены красным цветом с надписью «cannot evaluate expression».

    Процесс

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

    Show Execution Point ( Alt+F10 ) — переносит в файл и текущую линию отлаживаемого скрипта. Например, если файлов много, решили посмотреть что в других вкладках, а потом забыли где у вас отладка :)

    Step Over ( F8 ) — делает один шаг, не заходя внутрь функции. Т.е. если на текущей линии есть какая-то функция, а не просто переменная со значением, то при клике данной кнопки, отладчик не будет заходить внутрь неё.

    Step Into ( F7 ) — делает шаг. Но в отличие от предыдущей, если есть вложенный вызов (например функция), то заходит внутрь неё.

    Step Out ( Shift+F8 ) — выполняет команды до завершения текущей функции. Удобно, если случайно вошли во вложенный вызов и нужно быстро из него выйти, не завершая при этом отладку.

    Rerun ( Ctrl+F5 ) — перезапускает отладку.

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

    Stop ( Ctrl+F2 ) — завершает отладку.

    View Breakpoints ( Ctrl+Shift+F8 ) — просмотр всех установленных брейкпойнтов.

    Mute Breakpoints — отключает брейкпойнты.

    Итак, в текущем коде видно значение входного параметра:

    • $data = «23 24 11 18» — строка с данными через пробел
    • $nums = (4) [«23», «24», «11», «18»] — массив, который получился из входной переменной.

    Если нажмем F8 2 раза, то окажемся на строке 7; во вкладках Watches и Variables и в самой странице с кодом увидим, что переменная $sum была инициализирована и её значение равно 0.

    Если теперь нажмем F8 , то попадем внутрь цикла foreach и, нажимая теперь F8 , пока не окончится цикл, можно будет наблюдать на каждой итерации, как значения $num и $sum постоянно изменяются. Тем самым мы можем проследить шаг за шагом весь процесс изменения любых переменных и значений на любом этапе, который интересует.

    Дальнейшие нажатия F8 переместят линию кода на строки 11, 12 и, наконец, 15.

    Дополнительно

    Если нажать на View Breakpoints в левой панели, то можно не только посмотреть все брейкпойнты, но в появившемся окне можно еще более тонко настроить условие, при котором на данной отметке надо остановиться. В функции выше, например, нужно остановиться только когда $sum превысит значение 20.

    Это удобно, если останов нужен только при определённом значении, а не всегда (особенно в случае с циклами).

    Отладка исходного PHP кода в NetBeans IDE

    В этой статье я расскажу про отладку исходного php кода в NetBeans >

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

    Перед тем, как начать отладку исходного кода в NetBeans, нужно установить и настроить Xdebug на локальном сервере.

    После установки Xdebug можно настроить среду программирования NetBeans IDE.

    Первое, с чего нужно начать — это с настроек проекта в NetBeans. Щелкните по названию проекта в браузере проектов правой кнопкой мыши и откройте его свойства. В открывшемся окне, слева, в списке категорий выберите пункт «выполнить настройку»:

    В поле «URL-адрес проекта» наберите адрес вашего проекта на локальном сервере. В этой статье рассматривается отладка PHP скриптов, размещенных на локальном сервере. В поле «Файл индекса» выберите файл, с которого вы бы хотели начать отладку проекта. В PHP движках это обычно index.php. Далее, слева в списке выберите пункт «Браузер». Выберите браузер, в котором вы будете отлаживать ваш PHP проект. Я обычно оставляю в этом поле браузер по умолчанию. Нажмите «ОК».

    Зайдите в меню сервис->параметры, перейдите к пункту PHP и выберите вкладку «Отладка»:

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

    Все, теперь можно запускать отладку PHP скриптов, нажмите «Отладка проекта» на панели инструментов, или нажмите комбинацию клавиш Ctrl+F5.

    После этого в среде программирования откроется отлаживаемый файл скрипта. Если вы не убрали галочку «Остановиться в первой строке», выполнение отлаживаемого скрипта остановится на первой строке и она будет подсвечена зеленым цветом.

    После остановки скрипта вы можете выполнять его далее, пошагово, нажимая клавиши F7 или F8.

    При остановке скрипта, вы можете наблюдать значения переменных в окне «Переменные» (см. скриншот выше). Кроме окна «Переменные» в режиме отладки есть окно «Стек вызовов» и «Точки останова».

    При отладке вы можете смотреть содержимое переменных или вычислять выражения. При остановке скрипта в определенной точке выполнения выделите нужную переменную или участок кода и наведите на него мышкой, вы увидите значение этой переменной, или выражения (если оно к этому времени уже определено). Так же вы можете добавлять желаемые переменные или выражения в окно «Переменные» для дальнейшего просмотра их результата. Для этого выделите нужный участок кода, или переменную, нажмите на ней правой кнопкой мыши и в появившемся контекстном меню выберите «Создать наблюдение», либо нажмите Ctrl+shift+f7. После эта переменная (или выражение) появится в окне «Переменные» и по ходу отладки можно будет смотреть как изменяется ее значение.

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

    Поставив точку останова, запустите скрипт или продолжите отладку, нажав Ctrl-F5 для запуска или F5 для продолжения выполнения скрипта. Скрипт должен остановиться на созданной вами точке останова. После остановки скрипта вы можете выполнять его пошагово, нажимая клавиши F7 или F8.

    Часто отлаживаемый код бывает слишком большим и выполнять его пошагово, включая все циклы и условия, слишком муторно и долго. Чтобы этого избежать, можно «прыгать» от одного участка кода к другому, избегая те участки кода, отладка которых вам не нужна. Для этого нам пригодятся несколько точек останова. Например у вас в скрипте есть цикл, выполнять пошагово который придется долго, вам нужно пропустить этот участок кода с циклом и продолжить отладку дальше. Для этого нужно поставить одну точку останова перед циклом, а другую на участке кода ниже этого цикла. При остановке скрипта на первой точке останова нажмите «Продолжить» (зеленый кружок на панели отладки), либо F5, тогда скрипт продолжит свою работу, перепрыгнув участок кода между двумя точками останова, то есть выполнит цикл, и опять прервет свою работу на второй точке останова, которая была установлена после цикла. Таким способом можно эффективно отлаживать код скрипта, пропуская ненужные участки кода и останавливать выполнение скрипта в нужных местах. Вы можете поставить несколько точек останова в разных частях одного скрипта.

    Что делать, если отладка PHP кода в NetBeans не работает?

    Если у вас не ловятся точки останова, еще раз убедитесь, что xdebug правильно установлен и настроен.

    Далее зайдите в сервис->параметры->PHP->отладка, поставьте галочку у пункта «Останавливаться в первой строке». Запустите отладку. Если выполнение скрипта не остановилось на первой строке и в нижней части программы отображается надпись «ожидание подключение xdebug», то возможная причина может быть в том, что порт xdebug (по умолчанию 9000) занят какой то другой программой. Убедитесь в том, что 9000 порт не занят другой программой, или измените порт xdebug по умолчанию в настройках php.ini и укажите его в настройках NetBeans:

    Убедитесь в том, что ваш локальный веб-сервер правильно настроен и включен.

    Найдите ошибки в PHP-приложениях при помощи Xdebug

    Лучше использовать PHP-отладчик, чем echo с var_dump(), debug_zval_dump() и print_r()

    Хотя PHP можно использовать для создания сценариев командной строки для таких задач как системное администрирование и традиционная обработка данных, мощь языка особенно проявляется в Web-приложениях. В данной статье каждое PHP-приложение размещается на сервере и активизируется через прокси, такой как Apache, для обработки входящих запросов. Для каждого запроса за короткое время выполняется обычное PHP Web-приложение, выдающее Web-страницу или структуру XML-данных.

    Учитывая кратковременность выполнения Web-приложений и их уровневую конструкцию (клиентское приложение, сеть, HTP-сервер, прикладной код и применяемая база данных), отловить баги (bugs) в PHP-коде может быть непросто. Даже если предположить, что все уровни, за исключением PHP-кода, работают безупречно, трассировка до обнаружения ошибки в PHP-коде может быть трудной, особенно (с некоторой иронией) если приложение использует все больше и больше классов.

    PHP-выражение echo и функции var_dump() , debug_zval_dump() и print_r() являются обычными и очень популярными средствами отладки, помогающими решить различные проблемы. Однако как средства расследования эти выражения (и даже более надежный инструментарий, например, пакет PEAR Log) предоставляют доказательства, которые вы должны анализировать априори и вне контекста.

    Кроме того, отладка посредством дедукции является подходом с позиции «грубой силы». Вы собираете данные и просеиваете их, пытаясь понять, что произошло. При отсутствии необходимой информации вы должны переделать ваш код, повторить предыдущие действия и начать исследование заново. Намного более эффективная стратегия — испытывать приложение во время его работы. Можно каталогизировать параметры запроса, просмотреть стек вызовов процедур, узнать значение любой переменной или объекта. Можно временно прервать выполнение приложения и получить уведомление об изменениях значения переменной. В некоторых случаях можно фактически интерактивно изменять переменные, задавая вопрос «Что если?».

    Такое «живое» или интерактивное исследование обеспечивается специальным приложением, называемым отладчиком. Отладчик запускает или подключается к процессу для управления им и исследования его памяти. Либо, в случае с интерпретируемыми языками, отладчик может непосредственно интерпретировать код. Типичный современный отладчик может индексировать и просматривать исходный код, отображать сложные структуры данных в читабельном виде и одновременно отображать состояние программы, стек вызовов, выводимые программой данные и значения всех переменных. Например, для отладчика обычным является каталогизация и отображение свойств и методов класса.

    В этой и следующей статьях я познакомлю вас с инструментальными средствами, которые непременно упростят PHP-отладку. В следующий раз я сконцентрируюсь на интерактивной отладке и программе Zend Debugger (надежном отладчике, специально разработанном для PHP), а также рассмотрю множество функций, которые он предлагает (Zend Debugger — это коммерческий продукт, предоставляемый как часть Zend PHP Integrated Development Environment (IDE)). Также я рассмотрю PHP-отладчик с открытым исходным кодом, если вы предпочитаете тратить деньги на пиво, а не на программы. В данной статье я сконцентрируюсь на сборе более качественных доказательств.

    Как в сериале C.S.I., но применительно к компьютерам

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

    • «Где» — номер строки (и в каком она файле), после которой выполнение приложения прекратилось.
    • «Что» привело код в негодность — подозреваемый, так сказать.
    • «Почему» – в чем природа ошибки. Возможно, это логическая ошибка, ошибка, вызванная взаимодействием с операционной системой, или то и другое.
    • «Когда» — контекст, в котором возникла ошибка. Что случилось непосредственно перед гибелью программы? Как и в любом преступлении, улики могут изобличить преступника, если собрать достаточное их количество.

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

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

    Листинг 1. Процедуры для оснащения функции callee() новыми возможностями

    Этот код выводит:

    Компоновка и установка Xdebug

    Xdebug без труда компонуется из исходных кодов в UNIX®-подобных операционных системах, в том числе Mac OS X. Если вы используете PHP в Microsoft® Windows®, можете загрузить модуль Xdebug в бинарном виде для последних версий PHP с Web-сайта Xdebug (см. раздел «Ресурсы»).

    Давайте выполним компоновку и установим Xdebug для Debian «Sarge» Linux® и PHP V4.3.10-19. На момент написания данной статьи новейшей версией Xdebug является V2.0.0RC4, выпущенная 17 мая 2007 года. Для работы вы должны иметь служебные программы phpize и php-config, а также возможность изменять системный конфигурационный файл php.ini (если этих программ у вас нет, обратитесь на PHP.net за исходными кодами и инструкциями по компоновке PHP с нуля). Выполните следующие действия:

    1. Загрузите Xdebug tarball (сжатый gzip .tar-архив). Это очень сделать просто при помощи команды wget :
    2. Разархивируйте tarball и перейдите в каталог с исходным кодом:
    3. Запустите phpize , чтобы подготовить код Xdebug для вашей версии PHP:
      Результатом работы phpize является сценарий (очень к месту названный configure), используемый для настройки остального процесса компоновки.
    4. Выполните сценарий настройки:
    5. Выполните компоновку расширения Xdebug, запустив make :
      Результатом работы make является расширение Xdebug, xdebug.so.
    6. Установите расширение:
      Перед продолжением работы выделите и скопируйте каталог, который отобразила последняя команда. Этот путь очень важен для конфигурирования расширения на последнем шаге.
    7. Откройте файл php.ini в любимом текстовом редакторе и добавьте следующие строки:
      Первая строка загружает расширение Xdebug; вторая запрещает функциональность профайлера в Xdebug (для упрощения), а третья разрешает функциональные возможности отладки.


    Для проверки корректности установки и разрешения работы расширению Xdebug перезапустите ваш Web-сервер, затем создайте простое однострочное PHP-приложение с кодом . Если вы укажете адрес файла в браузере (например, http://localhost/phpinfo.php) и прокрутите выведенную информацию вниз, то увидите что-то похожее на рисунок 1.

    Рисунок 1. Проверка корректности установки и работы расширения Xdebug

    Примечание: Если раздела Xdebug нет в phpinfo() , Xdebug не загрузился. log-файлы ошибок вашего сервера Apache могут указать причину. К обычным ошибкам относится неправильный путь для zend_extension или конфликт с другим расширением. Например, если вы хотите использовать XCache и Xdebug, первым загружайте XCache. Однако, поскольку Xdebug предназначен для использования во время разработки и предполагая, что путь к xdebug.so указан правильно, запретите другие расширения и попробуйте еще раз. Затем можно повторно разрешить расширения для выполнения других проверок, например, эффективности кэширования. На сайте Xdebug приведены также некоторые другие советы по решению возможных проблем.

    Конфигурирование Xdebug

    Директивы (в самом левом столбце большой таблицы на рисунке 1) — это только некоторые из параметров, которые можно установить для изменения поведения расширения Xdebug. Все директивы указываются в файле php.ini. Некоторые из них конфигурируют средства отладки, другие настраивают работу профайлера. Игнорируя последние, давайте настроим Xdebug так, чтобы он помогал отлаживать PHP-код.

    Ограниченная рекурсия

    При использовании рекурсии (например, для вычисления чисел Фибоначчи) и некорректном указании условий завершения приложение может выполняться очень долго до тех пор, пока не использует все выделенное время или память. Для ограничения глубины рекурсии можно настроить параметр xdebug.max_nesting_level . Например, xdebug.max_nesting_level = 50 ограничивает рекурсию глубиной в 50 вложенных вызовов до принудительного завершения приложения. Для демонстрации выполните следующий код с разрешением работы Xdebug.

    Листинг 2. Ограничение рекурсии

    Функция deep_end() совершенно буквально ведет в глубокий тупик. Xdebug вмешивается в процесс после 49 вызовов функции и выдает информацию, приведенную на рисунке 2 (кстати говоря, начальная активизация main() для запуска программы считается первым фреймом).

    Рисунок 2. Xdebug завершает выполнение, если стек вызовов превышает его граничное значение

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

    Ответы на четыре простых вопроса

    При возникновении ошибок нужно ответить на четыре вопроса. Xdebug может предоставить всю нужную информацию, причем немедленно. Вот для начала несколько полезных настроек; их можно настроить более точно в любое время.

    Листинг 3. Ошибки

    Настройки xdebug.dump_once , xdebug.dump_globals , xdebug.dump_undefined и xdebug.dump_SUPERGLOBA L (где SUPERGLOBAL может быть COOKIE , FILES , GET , POST , REQUEST , SERVER или SESSION ) управляют тем, какие суперглобальные переменные PHP включаются во все диагностические результаты.

    Установите xdebug.dump_globals в значение On для вывода суперглобальных переменных, перечисленных в настройках xdebug.dump_SUPERGLOBAL . Например, xdebug.dump_SERVER = REQUEST_METHOD,REQUEST_URI,HTTP_USER_AGENT выводит суперглобальные переменные PHP $_SERVER[‘REQUEST_METHOD’] , $_SERVER[‘REQUEST_URI’] и $_SERVER[‘HTTP_USER_AGENT’] . Если вы хотите вывести все значения массива superglobal, используйте символ звездочки (*), например, xdebug.dump_REQUEST=* . Если вы установите xdebug.dump_undefined в значение On и не установите именованную переменную superglobal, она все равно выводится со значением undefined .

    Строка xdebug.show_exception_trace = On разрешает трассировку исключительных ситуаций, даже если вы перехватили исключительную ситуацию. Строка xdebug.show_local_vars = 1 выводит все локальные переменные самой внешней области видимости каждого вызова функции, включая еще не инициализированные переменные. А xdebug.var_display_max_depth = 6 указывает глубину вывода комплексной переменной.

    Объединение всех настроек

    В листинге 4 показаны все важные настройки для Xdebug в файле php.ini.

    Листинг 4. Настройки для файла php.ini

    Сохраните эти настройки в файле php.ini, а затем перезапустите ваш Web-сервер.

    Интерпретация данных дампа

    В следующем примере продемонстрировано, что происходит при возникновении ошибки. Измените код «off-the-deep-end» для соответствия листингу 5.

    Илон Маск рекомендует:  Модуль commands asm
    Листинг 5. Измененный ошибочный код

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

    Рисунок 3. Дамп суперглобальных, локальных переменных и переменных при ошибке

    Текст передаваемого в trigger_error сообщения показан вверху. Внизу расположен список запрошенных элементов $_SERVER и список определенных элементов $_REQUEST . В самом внизу находится список переменных области видимости #48 , что является вызовом deep_end() , согласно манифесту. В этом вызове переменная $count имела значение integer 48. С такой конфигурацией Xdebug вы теперь имеете больше улик для поиска преступника.

    Вот еще один совет: Xdebug предоставляет расширенную функцию var_dump() , которая особенно полезна для массивов и классов PHP. Например, в листинге 6 приведен простой (PHP V4) класс и экземпляры.

    Листинг 6. Класс и экземпляры PHP V4

    А в листинге 7 показана информация, выводимая функцией var_dump() .

    Листинг 7. Вывод var_dump()

    При использовании Xdebug с классами PHP V5 в дамп входят такие атрибуты как public , private и protected .

    Трассировка кода

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

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

    Так же как и для дампов, Xdebug имеет несколько параметров для настройки трассировки в php.ini. Следующие настройки, например, обеспечивают вывод наиболее подробной информации:

    Листинг 8. Настройка трассировки

    Настройка xdebug.auto_trace = 1 автоматически разрешает трассировку до выполнения любого PHP-сценария. В качестве альтернативы можно установить xdebug.auto_trace = 0 и использовать функции xdebug_start_trace() и xdebug_stop_trace() из вашего кода для разрешения и запрета трассировки соответственно. Однако если xdebug.auto_trace установлен в значение 1 , можно начать трассировку до включения сконфигурированного auto_prepend_file .

    Параметры xdebug.trace_ouput_dir и xdebug.trace_output_name управляют тем, где сохраняется информация трассировки. В данном примере все файлы сохраняются в /tmp/traces, и каждый файл начинается с trace , за которым следует имя PHP-сценария ( %s ) и идентификатор процесса ( %p ). Названия всех файлов трассировки Xdebug заканчиваются суффиксом .xt .

    По умолчанию Xdebug отображает поля времени, использования памяти, имени функции и глубины вызова функции. Если установить xdebug.trace_format в значение 0 , информация выводится в виде, удобном для чтения человеком (для машинного формата используется значение 1 ). Кроме того, можно обнаружить рост или уменьшение использования памяти при указании xdebug.show_mem_delta = 1 , а тип и значения входящих параметров можно выводить, указав xdebug.collect_params = 4 . Для отслеживания значения, возвращаемого каждой функцией, установите xdebug.collect_return = 1 .

    Пришло время другого примера. Создайте каталог /tmp/traces, измените его атрибуты на world-readable и world-writable при помощи mkdir /tmp/traces; chmod a+rwx /tmp/traces (если вы сомневаетесь в том, нужно ли делать этот каталог доступным для всех, по крайней мере, сделайте его доступным для пользователя Web-сервера — обычно www или nobody). Добавьте в файл php.ini указанные выше настройки, перезапустите Web-сервер и снова укажите в адресной строке браузера приложение phpinfo() . Информация трассировки должна выглядеть примерно так, как показано в листинге 9.

    Листинг 9. Полная трассировка

    Здесь main() вызывает phpinfo() , которая возвращает TRUE . Когда завершается main() , она возвращает 1 . Затем, укажите в адресной строке PHP-приложение «deep end» или какое-то другое для генерирования более реальной трассировки.

    В листинге 10 показана трассировка PHP-генератора чисел Фибоначчи из предыдущей статьи, вычисляющего четыре числа Фибоначчи:

    Листинг 10. Трассировка PHP-генератора чисел Фибоначчи

    В первом столбце показано время, во втором — суммарное использование памяти, в третьем — инкрементное использование памяти, в четвертом — вызовы функций, включая параметры.

    Строки, отмеченные символами >=> , показывают возвращаемое значение из каждой функции (для сопоставления вызова функции с возвращаемым ею значением нужно найти -> с соответствующим отступом). Опять же, последнее значение >=> 1 является значением, возвращаемым функцией main() .

    Для vim его автор Xdebug Дэрик Ретанс (Derick Rethans) предоставляет набор правил цветового выделения синтаксиса для файлов трассировки Xdebug. Эти правила содержатся в файле xt.vim в пакете исходных кодов Xdebug. В современных дистрибутивах Linux просто скопируйте xt.vim в $VIMRUNTIME/syntax/xt.vim, а затем запустите vim tracefile.xt . На рисунке 4 показана трассировка генератора чисел Фибоначчи с цветовым выделением в vim.

    Рисунок 4. Синтаксический файл vim для файлов трассировки Xdebug облегчает анализ

    Надоедливые PHP-паразиты в опасности

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

    Ресурсы для скачивания

    Похожие темы

    • Оригинал статьи «Squash bugs in PHP applications with Xdebug» (EN).
    • Посетите Xdebug.org (EN).
    • Документация по Xdebug (EN).
    • Дополнительная информация по использованию Xdebug приведена в статье developerWorks «Как сделать PHP-приложения быстрыми, еще более быстрыми, самыми быстрыми, часть 2: Профилирование PHP-приложения для поиска, диагностирования и ускорения медленного кода» (EN).
    • Загрузите расширение Xdebug.
    • PHP.net — центральный ресурс для PHP-разработчиков (EN).
    • «Рекомендованный список для чтения по языку PHP» (EN).
    • Усовершенствуйте свои навыки в PHP-программировании, используя ресурсы IBM developerWorks PHP project (EN).
    • Вещательные программы developerWorks — интересные интервью и дискуссии для разработчиков программного обеспечения (EN).
    • Используете базы данных в PHP? Обратите внимание на Zend Core for IBM, цельную, готовую к использованию, легкую в установке интегрированную среду разработки на PHP, поддерживающую IBM DB2 V9 (EN).
    • Раздел developerWorks Open source с исчерпывающей информацией how-to, инструментальными средствами и обновлениями проектов, помогающей использовать в разработке технологии с открытым исходным кодом и продукты IBM .
    • Разработайте ваш следующий проект с открытым исходным кодом, используя пробное программное обеспечение IBM, доступное для загрузки или на DVD.(EN)
    • Загрузите оценочные версии продуктов IBM и используйте инструментальные средства разработки приложений и программы промежуточного уровня DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.

    Комментарии

    Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

    Установка и настройка Xdebug

    Есть очень хороший инструмент для отладки php кода — Xdebug. Сегодня я расскажу как его развернуть на своей машине, а также как настроить NetBeans >

    Немного о Xdebug

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

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

    Установка Xdebug


    Уже довольно давно Xdebug, как расширение для php, присутствует в репозиториях. Поэтому его установка очень проста, для этого введите в консоли следующую команду.

    С установкой покончили. Перейдем к настройке.

    Настройка Xdebug

    Настройка расширения выполняется при помощи редактирования конфигурационных ini файлов. Тут есть два пути:
    1. В php.ini создаем секцию [xdebug] и в ней задаем параметры.
    2. Все параметры задаем в xdebug.ini, который хранится тут /etc/php5/conf.d/xdebug.ini
    Тут решать Вам и только Вам.

    Куда писать — определились. Определимся что писать?
    Давайте я приведу список настроек, и поясню, что они означают:

    После, необходимо чтобы наши изменения подтянулись.
    Для этого нужно перезагрузить apache или php-fpm (в зависимости от того, что Вы используете).

    Чтобы убедиться, что все хорошо, выведите
    phpinfo();
    Если такой текст имеется — значит все отлично:

    This program makes use of the Zend Scripting Language Engine:
    Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans

    Теперь проверим улучшенный var_dump:

    Вы должны увидеть красивый стилизированный вывод содержимого массива.
    Теперь создадим ошибку (забудем ; в конце строки)

    Вы должны увидеть подробное сообщение об ошибке, представляющее собой таблицу.

    Настройка PhpStorm

    Настройка NetBeans IDE

    Устанавливаем NetBeans, если он еще не установлен. Заходим в СервисПараметры. Переходим в меню PHP, далее вкладка Отладка (Debugging).
    И указываем следующие значения.
    Порт отладчика: 9000
    Идентификатор сеанса: netbeans-xdebug
    Хочу отметить, что порт сеанса, как и идентификатор сеанса могу быть другими. Например, можно указать идентификатор ide-xdebug , но тогда и в конфигах Xdebug придется указать такое же значение.

    Остальные параметры настраиваем под себя.

    Ну, а о том, как выполнять отладку — в другой раз.

    Отладка кода в PHP.

    Вы уже научились писать код на PHP, знаете MySQL и это хорошо, но как в любой программе есть ошибки, так и в вашем коде обязательно будут ошибки, от этого никуда не деться. Иногда это явные ошибки, к примеру забыли поставить в конце строки «;», иногда это не явные, когда все работает, но результат явно не тот который вы ожидали. Что тогда делать?

    Об этом, мы сейчас и поговорим.

    1. print_r() || var_dump() || var_export()

    Представим что у вас есть массив данных и вам надо его посмотреть, что же лежит внутри этого замечательного массива…

    Самый быстрый и простой способ
    [sourcecode language=»php»]
    print_r($array);
    [/sourcecode]
    И на странице, мы сможем увидеть внутренности нашего массива.
    [sourcecode language=»php»]
    Array ( [0] => a [q] => 22 [s] => 142 [dump] => Array ( [zero] => 5 [dump] => foo ) );
    [/sourcecode]
    Как видим, функция print_r() выдала нам не только данные, но и вывела структуру массива. Что очень может помочь.

    Данные можно передать в переменную, просто в качестве второго аргумента передайте TRUE.
    [sourcecode language=»php»]
    $var = print_r($array, TRUE);
    print $var;[/sourcecode]

    Это удобно, если нельзя делать вывод на страницу напрямую. Или для сохранения данных в базу.

    Но в данном выводе, не совсем понятно, [q] => 22, это число или это текст? А если надо вывести сразу 2 или более, переменных или массивов? Можно конечно использовать два и более раз функцию print_r(), и в этом даже нет ничего плохого. Но было бы удобней, сразу перечислить все переменные или массивы в одной функции и получить желаемый результат.

    Тут на помощь нам приходит var_dump()
    [sourcecode language=»php»]var_dump($array);[/sourcecode]
    выдаст
    [sourcecode language=»php»]
    array(4) < [0]=>string(1) «a» [«q»]=> int(22) [«s»]=> string(3) «142» [«dump»]=> array(2) < ["zero"]=>string(1) «5» [«dump»]=> string(3) «foo» > >
    [/sourcecode]
    Как видно, уже больше информации выдало нам. Теперь нам известно, где текст, а где число.
    И в таких случаях
    [sourcecode language=»php»]
    if(is_int($array[‘s’])) <
    //некое действие
    >
    [/sourcecode]
    Мы сразу поймем, почему не работает данное условие.

    Также, можно указать сразу два массива или более, в данной функции и получить вывод сразу всех массивов.

    Создадим еще один массив,
    [sourcecode language=»php»]
    $clone_array = array(‘1’=>’b’,’boo’=>’541′, ‘z’=>’44’, ‘relese’=> array (‘one’=>’11’, ‘dump’=>’zoo’));
    [/sourcecode]
    И получаем вывод.
    [sourcecode language=»php»]
    array(4) < [0]=>string(1) «a» [«q»]=> int(22) [«s»]=> string(3) «142» [«dump»]=> array(2) < ["zero"]=>string(1) «5» [«dump»]=> string(3) «foo» > > array(4) < [1]=>string(1) «b» [«boo»]=> string(3) «541» [«z»]=> string(2) «44» [«relese»]=> array(2) < ["one"]=>string(2) «11» [«dump»]=> string(3) «zoo» > >
    [/sourcecode]
    Помимо указания где int, а где string, var_dump(), указывает и другие типы данных, float, bool, resource, array, object.

    Третья функция var_export(), это почти тоже самое, что и var_dump(), только возвращает представление является правильным РНР-кодом.

    Вот вывод.
    [sourcecode language=»php»]
    array ( 0 => ‘a’, ‘q’ => 22, ‘s’ => ‘142’, ‘dump’ => array ( ‘zero’ => ‘5’, ‘dump’ => ‘foo’, ), )
    [/sourcecode]
    Данный вывод можно скопировать в код и он будет рабочим. Так иногда можно вытащить динамический массив из кода, для дальнейшей работы с ним.

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

    Попробуйте в этой каше разобраться? Даже я, зная структуру данного объекта, не сразу могу найти нужное значение.

    Для чтения больших массивов, лучше использовать другие инструменты.

    2. krumo()

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

    А если еще короче, то krumo() это замена “print_r() || var_dump() || var_export()”

    Причем красивый и очень удобный аналог. В php по умолчанию его нет, скачать его можно тут

    Работать с ним также легко, как и с “print_r() || var_dump() || var_export()”

    Скачайте и распакуйте его в корень сайта

    Сперва, надо провести начальную настройку, хоть это не обязательно, но так будет лучше.

    Там всегда две строки которые надо изменить.

    [sourcecode language=»text»]1. [skin]

    url = «http://www.example.com/Krumo/»
    [/sourcecode]

    В комплекте, идет 6 внешних видов вывода. Посмотреть их можно в папке skins. Выбирайте любой и вписывайте название в 1.

    [sourcecode language=»text»]
    1. [skin]
    selected = «green»
    [/sourcecode]
    В 2, надо прописать путь к папки с krumo.
    [sourcecode language=»text»][css]
    url = «/krumo/»
    [/sourcecode]
    Вот и вся настройка. Krumo() будет работать и без этих настроек, просто с ними будет красивей и наглядней.

    Для использования krumo(), выполняем
    [sourcecode language=»php»]
    include(‘krumo/class.krumo.php’);
    [/sourcecode]
    После чего, просто и легко, пишем
    [sourcecode language=»php»]
    krumo($array);
    [/sourcecode]
    и получаем вот такую красоту

    На первой картинке видим, как изначально все выглядит. На второй картинке, мы видим что будет если раскрыть наш массив, клацнув на нем мышкой.

    Поддерживается любой массив, объект, переменная и тп и тд, любой глубины и с любыми данными.

    А вот так выглядит мой огромный объект

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

    Krumo() поддерживает вывод сразу нескольких массивов за раз.
    [sourcecode language=»php»]
    krumo($array, $clone_array, $clone_array);
    [/sourcecode]

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

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

    3. xDebug

    xdebug – это расширение для отладки и трассировки кода в PHP, написанное Derick Rethans, одним из разработчиков языка PHP.

    Если у вас вебсервер Denver, то данное расширение уже стоит.

    Для других напишу как быстро установить.

    1.Создаем файл (к примеру в корне localhost) phpinfo.php с содержимым
    [sourcecode language=»php»]
    phpinfo();
    [/sourcecode]

    2. После чего открываете www.localhost/phpinfo.php
    Будет выведена страница с информацией о PHP, нам нужно открыть исходный кодстраницы. Для этого жмем ctrl+u, копируем весь исходный код страницы и вставляем на странице http://xdebug.org/wizard.php и жмем «Analyse my phpinfo() output»
    Вам будет выдана информация, какой файл нужно качать и что писать в php.ini
    3. Качаем рекомендуемый файл и сохраняем его на жестком диске куда вам хочется или в папку с расширениями php.
    4. Открываем php.ini, посмотреть где он находится можно легко www.localhost/phpinfo.php, там можно найти информацию где лежат расширения для PHP.
    Пишем в php.ini
    [sourcecode language=»text»]
    [xdebug]
    zend_extension = \usr\local\php5\ext\php_xdebug-2.2.1-5.3-vc9.dll
    [/sourcecode]
    или
    [sourcecode language=»text»]
    [xdebug]
    zend_extension_ts = \usr\local\php5\ext\php_xdebug-2.2.1-5.3-vc9.dll
    [/sourcecode]
    Зависит от версии PHP. Вам на странице http://xdebug.org/wizard.php указали что нужно писать.
    5. Перезагружаем webserver.
    Проверить, правильно ли все, можно www.localhost/phpinfo.php
    Там должно быть подобное

    Установка завершена, переходим к настройке.

    После строки с
    [sourcecode language=»text»]
    zend_extension
    [/sourcecode]
    в php.ini дописываем
    [sourcecode language=»text»]
    [xdebug]
    zend_extension=»\usr\local\php5\ext\php_xdebug-2.2.0-5.3-vc9.dll»
    xdebug.default_enable = On
    xdebug.profiler_enable = Off ;Off
    xdebug.profiler_enable_trigger = On
    xdebug.profiler_output_dir = «/tmp/xdebug»
    xdebug.profiler_append = On
    xdebug.profiler_output_name = «xdebug.out.%t.%s»
    xdebug.auto_trace = Off
    xdebug.trace_format = Off
    xdebug.collect_params = 1
    xdebug.collect_return = 1
    xdebug.collect_includes = 1
    xdebug.trace_options = 1
    xdebug.trace_output_dir = «/tmp/xdebug/trace»
    [/sourcecode]
    Обязательно создайте папки:
    [sourcecode language=»text»]
    xdebug.trace_output_dir = «/tmp/xdebug/trace»
    xdebug.profiler_output_dir = «/tmp/xdebug»
    [/sourcecode]
    Или укажите свои.

    Все готово для профилирования или трассировки.
    Но начнем с var_dump и вывода ошибок. :-)
    Благодаря xDebug, вывод ошибок и вывод var_dump стали более красивые и структурированными.
    Пример ошибки

    А вот так выводится var_dump()

    Согласитесь, стало намного лучше, того что было.

    Переходим к профилированию.

    Профилирование

    Так как профилирование очень дорогое удовольствие и не на каждой странице нужно проводить профилирование, профилирование по умолчанию отключено. Чтобы включить его для определенной страницы, надо в конец url добавить ?XDEBUG_PROFILE Это позволить запустить процесс профилирования. В корне сайта я сделал файл test.php c содержимым
    [sourcecode language=»php]
    $array = array(‘0’=>’a’,’q’=>22, ‘s’=>’142’,’dump’=>array(‘zero’=>’5′,’dump’=>’foo’));
    include(‘krumo/class.krumo.php’);
    krumo($array);
    [/sourcecode]

    В папке «tmp\xdebug» должен быть файл с длинным именем
    [sourcecode language=»text]
    cachegrind.out.1354193532.Z__home_localhost_www_test_php
    [/sourcecode]
    где
    1354193532 — timestamp
    Z_home_localhost_www_test_php — путь к скрипту который мы профилировали, слеш и точка с двоеточием, были заменены на нижние подчеркивание.

    Если открыть данный файл, то там будет примерно 1000 строчек текста, в котором реально разобраться нельзя.

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

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

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

    Трассировка

    По умолчанию трассировка отключена. По той причине, что если начать трассировать весь сайт, это может закончится много километровыми логами, на изучение которого уйдет не один день. Чтобы лишние не трассировать, есть специальная функции
    [sourcecode language=»php]
    xdebug_start_trace(); //- начало трассирования.
    xdebug_stop_trace(); //- конец трассирования.
    [/sourcecode]
    Если трассировать класс krumo(), то там будет вывод на несколько тысяч строк. Для примера, очень много, поэтому изменим немного наш код. Создадим функцию с рекурсией. Рекурсия одна из головных болей программиста, не всегда ясно, что она выполняет и когда заканчивается. Мы же создадим простую функцию с рекурсией, которая выводит значения массива в строку.
    [sourcecode language=»php»]
    $array = array(‘0’=>’a’,’q’=>22, ‘s’=>’142’,’dump’=>array(‘zero’=>’5′,’dump’=>’foo’));

    foreach ($array as $key => $value) <
    if(is_array($value)) <
    $variable .= recursion($value);
    >else <
    $variable .= $value;
    >
    >
    return $variable;
    >
    [/sourcecode]

    Заходим http://localhost/test.php и в папке «/tmp/xdebug/trace», мы видим файл трассировки.
    С ним сложней и проще одновременно.
    Сложней, потому что нет спец.программ для его чтения.
    Но проще, потому, что и не нужно.
    Откройте файл трассировки в любом текстовом редакторе.

    Мы видим пошаговое выполнение нашего кода.


    • Первая колонка это время выполнения скрипта. Значение в секундах
    • Вторая колонка, это используемая память на данный момент. Значение в байтах
    • Третья колонка это что именно на тот момент выполнялось.

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

    Выводить можно и в html формате. Для этого надо

    заменить
    [sourcecode language=»php»]
    xdebug_start_trace();
    //на
    xdebug_start_trace(‘C:\test.html’, XDEBUG_TRACE_HTML);
    [/sourcecode]
    Но информации выводится меньше. Поэтому лучше использовать первый вариант.

    Я показал основы отладки кода в PHP. Конечно это не все, но на данном этапе, вам хватит за глаза и этого.

    P.S. Для просмотра логов профилирования, лучше использовать http://sourceforge.net/projects/xcallgraph/

    Я его нашел уже после написания статьи, поэтому не стал исправлять.
    Для Linux есть лучше вариант, это kcachegrind. Для Windows он тоже есть, но работает кривовато.

    Поделиться

    Комментарии Правила дискуссии

    1. Участники дискуссии уважительно относятся друг к другу и к автору блога.
    2. Мат недопустим. Учитесь вести диалог культурно.
    3. Реклама и спам запрещены.

    Если вы не соблюдаете эти три простых правила, то ваши комментарии удаляются без предупреждения.

    Во всем остальном вам предоставляется полная свобода слова и выражения собственного мнения.

    Отладка PHP-приложений в Docker с помощью PhpStorm и Xdebug

    В предыдущей статье мы разобрали, как настроить локальную среду разработки с помощью Docker Compose. Сегодня мы разберемся, как настроить отладку php-приложений в Docker c помощью Xdebug.

    Xdebug является незаменимым инструментом при разработке приложений на php, т.к. позволяет пошагово отследить выполнение приложения, увидеть значения всех переменных во время выполнения. Помимо отладки, Xdebug имеет ряд других полезных функций: профайлинг, генерация отчета code coverage для PHPUnit и другие.

    Настройка отладки в PhpStorm

    Откроем настройки PhpStorm: Languages & Frameworks > PHP > Debug:

    В настройках устанавливаем, что Xdebug будет ожидать соединений на порту 9000 (по умолчанию).

    Далее в настройках выбираем пункт Servers и добавляем новый сервер «Docker server»:

    Указываем хост и порт, на котором доступен ваш Docker сервер. Далее устанавливаем маппинг нашей локальной директории с проектом с директорией проекта внутри контейнера: в левой колонке указывается абсолютный путь проекта на локальной машине, в правой колонке — абсолютный путь к директории проекта в контейнере ( /test_project в моем случае). После этого сохраняем изменения.

    Далее в верхнем меню выбираем Run > Edit configurations. , нажимаем на + и выбираем пункт PHP Remote Debug:

    В открывшемся окне в поле Servers выбираем созданный нами ранее сервер, а в поле ide key указываем PHP_STORM (эта переменная должна совпадать с переменной, которую мы укажем в настройках контейнера).

    На этом настройка окончена и PhpStorm готов принимать соединения Xdebug для отладки.

    Установка расширения xDebug

    Xdebug не входит в исходники PHP, поэтому для его установки воспользуемся библиотекой PECL. Добавим следующую строку в Dockerfile проекта:

    В данном случае мы воспользовались специальным встроенным скриптом для активации расширения docker-php-ext-enable. Подробнее об установке и настройке расширений можно прочитать в документации официального docker-контейнера PHP.

    Теперь настроим Xdebug в соответствии с нашими настройками PhpStorm. Для этого добавим следующий скрипт в Dockerfile:

    Расшифруем настройки, указанные выше:

    • xdebug.remote_enable=1 — активируем удаленную отладку
    • xdebug.remote_port=9000 — указываем Xdebug отправлять запросы на порт 9000
    • xdebug. > — указываем idekey, который мы ранее указали в настройках PhpStorm
    • xdebug.remote_host=172.18.0.1 — указываем ip адрес host-машины, т.к. Xdebug должен установить соединение с нашим компьютером для отправки отладочной информации. Вы можете узнать его, выполнив команду /sbin/ip route|awk ‘/default/ < print $3 >‘ внутри контейнера. Другие варианты можно посмотреть здесь: https://stackoverflow.com/questions/22944631/how-to-get-the-ip-address-of-the-docker-host-from-inside-a-docker-container
    • xdebug.remote_connect_back=0 — отключаем эту опцию, т.к. она перезапишет настройку remote_host
    Илон Маск рекомендует:  Что такое код metaphone

    После этого нужно пересобрать контейнер, чтобы новое расширение было установлено. Если вы используете Docker Compose, то пересобрать и запустить контейнер можно с помощью команды: docker-compose up —build .

    Запуск отладки

    Для начала отладки нужно разрешить PhpStorm принимать соединения от Xdebug (иконка с телефонной трубкой в правом верхнем углу окна) и выбрать из списка созданную нами ранее конфигурацию (Docker):

    После установим breakpoint в коде проекта — для этого нужно кликнуть слева от нужной строки кода:

    Теперь откроем наш проект в браузере. В PhpStorm должно появиться окно с входящим соединением Xdebug, которое нужно принять:

    Теперь вы можете пошагово выполнять ваш код и отслеживать значения всех переменных!

    Отладка исходного кода PHP в IDE NetBeans

    Для работы с этим учебным курсом требуется следующее программное обеспечение и ресурсы.

    Программное обеспечение или материал Требуемая версия
    IDE NetBeans Пакет загрузки PHP
    Механизм PHP Версия 5
    Веб-сервер Рекомендуется использовать сервер HTTP Apache версии 2.2.
    Отладчик PHP Версия XDebug 2.0 или выше

    Подготовка

    Для успешной отладки приложений PHP в IDE NetBeans для PHP, требуется механизм PHP, локальный веб-сервер Apache и отладчик XDebug, установленный и настроенный для разработки PHP. Если возникают проблемы с запуском XDebug, см. материалы по XDebug на вики-сайте NetBeans и/или обратитесь к сообществу по адресу

    How PHP Debugging with XDebug Works in IDE NetBeans

    When you run XDebug from IDE NetBeans, PHP program execution pauses at every line where you set a breakpoint. Когда исполнение программы установлено на паузу, XDebug может извлечь информацию о текущем состоянии программы, такую, как значения переменных программы. Фактически это означает следующую последовательность выполняемых действий:

    1. Установите точку останова в каждой строке, на которой исполнение исходного кода PHP должно приостановиться.
    2. Начните сеанс отладки.
    3. Когда достигнута строка с точкой останова, исполняйте сценарий по одной строке, нажимая F7 и F8. Отслеживайте состояние приложения в окнах отладчика.
    4. Закройте сеанс отладки.

    For a detailed workflow of using XDebug with IDE NetBeans, see Debugging Session.

    IDE NetBeans обеспечивает панель инструментов отладки, которая используется для пошагового перехода между файлами. См. Работа с панелью инструментов и редактором

    Параметры отладки

    Параметры IDE NetBeans включают вкладку для изменения определенных настроек по умолчанию для отладки PHP. Чтобы открыть эти параметры, зайдите в Tools («Средства») > Options («Параметры») (NetBeans > Preferences («Настройки») на Mac), выберите параметры PHP, после чего выберите вкладку Debugging («Отладка»).

    Примечание . Вкладка ‘Отладка’ была реализована в IDE NetBeans версии 7.1. В более ранних версиях NetBeans на вкладке ‘Общие’ PHP имеются параметры отладки. Не все параметры версии 7.1 доступны в предыдущих версиях.

    В данной панели можно изменить следующие параметры:

      Debugger port («Порт отладчика») Это порт, используемый XDebug и установленный в php.ini. По умолчанию используется порт 9000. Номер порта в этом диалоге должен совпадать с номером порта отладчика, установленным в php.ini. В данном диалоговом окне нельзя изменить порт, используемый XDebug. В >Примечание. Задайте output_buffering = Off в используемом файле php.ini. иначе выводы сценариев будут появляться в окне вывода с задержкой.

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

    Работа с панелью инструментов и редактором

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

    Использование панели инструментов отладчика

    При запуске сеанса над редактором отладки отображается панель инструментов отладчика.

    Панель инструментов предоставляет возможности выполнения следующих действий:

    Завершить сеанс ( ) Завершение сеанса отладки
    Приостановить ( ) Приостановка сеанса отладки
    Возобновить ( ) Возобновление сеанса отладки
    Обход процедур ( ) Переход к следующему оператору выполнения
    Вход в ( ) Переход к вызову функции
    Выходt ( ) Выход из текущего состояния вызова функции
    Переход к курсору ( ) Запуск выполнения с позиции курсора

    Установка точек останова

    Точки останова, установленные в файлах, указывают позицию, в которой отладчик должен прервать выполнение кода.

    Важно! Для использования XDebug в коде PHP необходимо установить точки останова.

    Для установки точки останова щелкните в левом поле редактора строку, в которой необходимо установить эту точку.

    Чтобы удалить точку останова, щелкните маркер точки останова ( ).

    Также можно временно отключить точки останова. Для этого щелкните правой кнопкой мыши значок точки останова и снимите выделение с ‘Точка останова’ > ✔’Включено’. Выполняется переключение точки останова в отключенное состояние, после чего маркер выделяется серым ( ) и отображается на левом поле.

    Если отладчик во время работы достигает точки останова, отладка приостанавливается, что позволяет просмотреть значения в окнах отладки и перейти к любому месту кода после точки останова.

    Просмотр всплывающих подсказок

    Когда работа отладчика приостановлена в время сеанса отладки, можно навести мышь на идентификатор PHP в редакторе для отображения подсказки. Если идентификатор действителен в выбранном окне стека вызовов, отображается его значение. Также можно выбрать выражения PHP. Значение выражения отображается в подсказке.

    Окна отладчика

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

    Все окна отладки можно вызвать из среды IDE путем выбора «Window > Debugging». После активации сеанса отладки можно перейти в окна отладки.

    Окно «Sessions»


    В окне «Sessions» отображаются сеансы отладки, активные в настоящий момент. При запуске сеанса отладки PHP запись для отладчика PHP можно увидеть в окне Sessions («Сеансы»).

    IDE NetBeans также позволяет запускать одновременно несколько сеансов отладчиков. Например, можно одновременно отлаживать проект Java и проект PHP. В данном случае можно определить два сеанса, перечисленных в окне Sessions («Сеансы»).

    Текущий сеанс (т.е. сеанс, которым можно управлять с помощью панели инструментов отладчика) отмечен более заметным значком ( ). Для переключения сеансов дважды щелкните сеанс, который необходимо сделать текущим или щелкните правой кнопкой мыши сеанс, который не является текущим и выберите ‘Сделать текущим’.

    Примечание. Рекомендуется воспользоваться переключением сеансов, если текущий сеанс отложен.

    Также можно щелкнуть правой кнопкой мыши всплывающее окно для завершения сеанса (щелкните правой кнопкой мыши и выберите ‘Завершить’) или переключитесь между отладкой текущего потока или всех потоков в сеансе (щелкните правой кнопкой мыши и выберите ‘Область’ > ‘Отладка всех потоков’ или ‘Отладка текущего потока’).

    Окно «Variables»

    Когда работа отладчика приостановлена, в окне Variables («Переменные») отображаются переменные текущего объекта window для выбранного кадра стека вызовов. Узел отображается для каждой переменной в текущем окне. Суперглобальные переменные группируются в отдельном узле.

    По мере продвижения по коду значение некоторых локальных переменных может меняться. Такие локальные переменные в окне «Local variables» отображаются полужирным шрифтом. Также можно щелкнуть непосредственно столбец «Value» и вручную изменить значения переменной.

    Окно «Watches»

    Установка точек наблюдения нарушает стабильную работу XDebug и не рекомендуется. По умолчанию точки наблюдения отключены. Однако, если точки наблюдения все же нужно установить, см. Использование дополнительных точек наблюдения.

    Окно «Call Stack»

    В окне «Call Stack» («Стек вызовов») представлена последовательность вызовов, осуществленных в процессе выполнения. При приостановке отладчика в окне «Call Stack» отображается последовательность вызовов функций (т.е. стек вызовов). При первой приостановке автоматически выделяется самое верхнее окно стека вызовов. Дважды щелкните вызов функции в окне, чтобы перейти к этой строке в редакторе. Если выполнен вызов к классу PHP, окно навигатора также переместится к этой строке, если дважды щелкнуть вызов.

    Можно дважды щелкнуть кадр стека вызовов, чтобы выбрать его, а затем рассмотреть значения переменных или выражений для данного кадра в окнах Variables («Переменные») и Watches («Точки наблюдения»).

    Окно «Threads»

    Окно Threads («Потоки») указывает, какой сценарий PHP активен в настоящий момент и выполняется ли он, либо находится на точке останова. Если сценарий выполняется, необходимо перейти в окно браузера для взаимодействия с ним.

    Окно «Sources»

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

    Окно «Breakpoints»

    Для просмотра всех точек останова, установленных в среде IDE, можно использовать окно «Breakpoints».

    Из окна Breakpoints можно включать или отключать точки останова в окне Context («Контекст»). Также можно создавать группы точек останова.

    Сеанс отладки

    Следующая процедура представляет собой последовательность выполняемых действий в типичном сеансе отладки.

    Для запуска сеанса отладки выполните следующее:

    1. Запустите среду IDE и откройте файл, содержащий исходный код, который необходимо отладить.
    2. Установите точку останова в каждой строке, где отладчику следует приостановить работу. Для установки точки останова, поместите курсор в начало строки и нажмите Ctrl-F8 / ⌘-F8 или выберите ‘Отладка’ > ‘Переключение точек останова на строке’
    3. В окне ‘Проекты’ перейдите к узлу текущего проекта, щелкните правой кнопкой мыши и выберите ‘Отладка’ во всплывающем меню. Среда IDE открывает окна отладки и выполняет проект в отладчике до достижения установленной точки останова.
      Примечание. Если текущий проект настроен как ‘Главный’ выберите ‘Отладка’ > ‘Отладка главного проекта’ или нажмите Ctrl-F5, или щелкните .
    4. Перейдите в окно «Local Variables». В данном окне показаны все переменные, которые инициализированы внутри текущей функции, их типы и их значения.
    5. Для просмотра значения переменной отдельно от функции переместите курсор на отображаемую переменную. Подсказка показывает значение переменной.
    6. Для построчного выполнения программы (включая строки внутри всех вызванных функций) нажмите F7 или выберите «Debug > StepInto» и наблюдайте за изменениями значений переменных в окне «Локальные переменные».
    7. Для проверки логики программы путем наблюдения за изменениями выражений определите новый параметр наблюдения:
      1. Для открытия окна «Watches » выберите путь «Window > Debugging > Watches» или нажмите сочетание клавиш Ctrl-Shift-2. Откроется окно «Watches».
      2. Щелкните окно «Watches» правой кнопкой мыши и выберите «New Watch» во всплывающем меню. Откроется окно «New Watch».
      3. Введите наблюдаемое выражение и нажмите OK.

      Теперь в течение отладки можно выполнить дополнительную проверку.

      Важно! Для установки точек наблюдения необходимо включить точки наблюдения на вкладке Debugging («Отладка») параметров PHP.

      После завершения программы окна отладки закрываются.

      Пример сеанса отладки

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

      1. Создайте новый проект PHP со следующими параметрами:
        • Тип проекта – приложение PHP
        • Расположение исходных файлов – по умолчанию папка htdocs
        • Настройка выполнения – локальный веб-сайт

        Для получения более подробной информации о настройке проекта PHP см. Настройка проекта PHP.

      2. Для активации возможности использования «горячих» клавиш во время сеанса установите курсор на узел проекта и выберите «Set as Main Project» во всплывающем меню.
      3. Введите следующий код в файле index.php: Этот код содержит три функции:
        • функция calculate_factorial ();
        • функция calcualte_sum ();
        • функция calculate_sum_of_factorials () (дважды вызывает функцию calculate_factorial, затем однократно вызывает функцию calcualte_sum () и возвращает рассчитанную сумму факториалов).
      4. Задайте точку останова (Ctrl-F8/⌘-F8) в начале блока PHP:
      5. Для начала отладка щелкните . Отладчик остановится по достижении точки останова.
      6. Нажмите F7 три раза. Отладчик остановится в той строке, в которой вызывается функция calculate_sum_of_factorials (). В окне «Local Variables» отображаются переменные $m и $n с соответствующими значениями:
      7. Нажмите F7 для перехода к функции calculate_sum_of_factorials(). Отладчик начнет выполнение кода внутри функции calculate_sum_of_factorials () и остановится при вызове функции calculate_factorial().

      Теперь в окне «Local Variables» отображаются локальные переменные $argument1 и $argument2, заявленные в функции calculate_sum_of_factorials ().

    8. Нажмите F7. Отладчик начнет выполнение кода с функцией calculate_factorial(). В окне «Call Stack» отображается стек вызовов функций в обратном порядке, начиная с последней вызванной функции:
    9. Нажмите F7 для перехода к циклу. Просмотрите значения переменных в окне Variables («Переменные»).
    10. После подтверждения правильности работы кода нажмите Ctrl-F7/⌘-F7, чтобы отменить выполнение функции. Затем будет выполнен возврат к строке, следующей после строки вызова функции calculate_factorial().
      Примечание. В качестве альтернативы можно нажимать F7 до завершения программой выполнения функции calculate_factorial(). После вызова этой функции также будет выполнен возврат к следующей строке.
    11. Поскольку проверка функции calculate_factorial() была только что выполнена, и известно, что функция работает нормально, ее выполнение можно «пропустить». Для этого нажмите F8. Программа завершит работу при вызове функции calculate_sum().
    12. Для перехода к функции calculate_sum() нажмите F7.
    13. Для этого нажмите F8. В любом случае отладчик остановится на последней строке в функции calculate_sum_of_factorials().
    14. Нажмите F7. Отладчик переместится к строке с оператором echo.
    15. Нажимайте F7 до тех пор, пока отладчик не завершит работу с программой. Откроется окно браузера, в котором отображается результат выполнения программы:

    Использование дополнительных наблюдаемых выражений

    В целях дальнейшего выполнения программы можно определить дополнительное наблюдаемое выражение. Это может способствовать обнаружению ошибок.

    Внимание! Настройка дополнительных точек наблюдения нарушает стабильную работу XDebug. По умолчанию точки наблюдения отключены в параметрах отладки.

    1. Обновите код, как показано ниже (замените знак «плюс» на знак «минус»): Можно предположить, что это следствие неправильного написания кода, но фактически требуется еще раз подсчитать сумму.
    2. Выберите ‘Отладка’ > ‘Создать наблюдение’ или нажмите Ctrl/⌘-shift-F7. Откроется окно «New Watch».
    3. Введите следующее выражение и нажмите «ОК». Новое выражение появится в окне «Watches».
    4. Запустите сеанс отладки. После остановки отладчика остановится в указанной строке: сравните значение выражения в окне «Watches» со значением $result в окне «Local Variables». Эти значения должны совпадать, но они различны.

    Этот пример является простым, однако позволяет получить некоторое представление об использовании наблюдаемых выражений.

    Использование сочетания PHP и HTML

    Дополнительная информация о формах ввода HTML.

  • Замените следующие строки в верхней части блока : на следующий код:
  • Установите точку останова в начале блока и начните сеанс отладки.
  • Нажмите F7. Отладчик перейдет к программе. Откроется окно браузера, но форма ввода в нем не отображается. Это нормальный режим работы отладчика, поскольку для отображения веб-страницы отладчик должен пройти по всему исходному коду. Фактически это означает, что отладчик обрабатывает код дважды. Первый раз обрабатывается код для отображения формы ввода HTML. Второй раз поэтапно обрабатывается код PHP.
  • Нажимайте F7 до тех пор, пока не будет достигнут конец программы; после этого откроется форма ввода.
  • Заполните форму и нажмите Enter. Сеанс отладки будет продолжен, как описано в разделе Пример сеанса отладки.
  • Отображение пути, прокси отладчика и запуск сеанса отладки по пользовательскому URL-адресу

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

    Чтобы настроить сопоставление путей и разрешить использование пользовательских URL-адресов при отладке:

    1. Щелкните правой кнопкой узел проекта в окне Projects («Проекты») и откройте свойства проекта в контекстном меню.
    2. В диалоговом окне ‘Свойства проекта’ перейдите в категорию ‘Конфигурация запуска’.
    3. Нажмите кнопку Advanced («Дополнительные»). Откроется диалоговое окно расширенной настройки сети.
    4. Добавьте путь сервера и путь проекта для сопоставления путей.
    5. В Debug URL («Отладка URL-адреса») выберите один из следующих вариантов (не оставляйте выбор по умолчанию):
    • Ask Every Time («Спрашивать каждый раз»), указывающий среде IDE запрашивать URL-адрес у пользователя при каждом запуске сеанса отладки.
    • Do Not Open Web Browser («Не открывать веб-браузер»), в результате чего придется открыть браузер и ввести URL-адрес вручную (будет необходима переменная GET/POST XDEBUG_SESSION_START).
  • В случае использования для отладки прокси-сервера введите имя узла и порт сервера в разделе Debugger Proxy («Прокси отладчика»).
  • Дополнительные сведения приведены в записи Path Mapping in PHP Debugger («Сопоставление путей в отладчике PHP») блога по Net Beans для PHP.

    Для отправки комментариев и предложений, получения поддержки и новостей о последних разработках, связанных с PHP IDE NetBeans присоединяйтесь к списку рассылки .

    Отладка PHP кода в PhpStorm с использованием Xdebug

    Основным преимуществом использования PhpStorm вместо блокнота при написании кода является возможность использования отладчика (или «дебаггера»). Отладчик позволяет проникнуть внутрь кода для отслеживания изменения переменных и анализа логики его работы на различных этапах исполнения скрипта или движка, в нашем случае — Drupal.

    Скажу честно, что я начал активно использовать дебаггер только спустя полутора лет web-разработки. Да, я считал, что надо «писать код бляць» и не отвлекаться на изучение каких-то непонятных дебаггеров. Но в конечном счете мне пришлось столкнуться с серьезной командной разработкой, где без использования отладчика делать было нечего. Поэтому мой вам совет: потратьте один, да хоть и два дня, но разберитесь в тонкостях работы с PHP отладчиком. Ну а я вам в этом постараюсь помочь.

    В рамках этой статьи будет рассмотрена связка OpenServer, Xdebug (по умолчанию идет с OpenServer) и PhpStorm — про первичную настройку среды разработки я уже писал, рекомендую начать с нее. Также нам потребуется уже созданный локальный сайт и проект в PhpStorm – у меня это будет www.angarsky.loc .

    Конфигурация отладчика в PhpStorm

    Настраивать отладчик мы будем на примере index.php – начинайте настройку именно с этой страницы, т.к. при запуске движков она обязательно отрабатывает.

    В раскрывшемся окне первым делом жмем на значок «+» и выбираем PHP Web Application. Заполняем поле Name, выбираем ваш любимый браузер для разработки и в качестве Start URL указываем страницу сайта для стартового запуска. Обратите внимание, что указывается относительный путь.

    Следующим шагом будет конфигурирование Server. Опять же жмем «+» , заполняем Name, Host и Use path mappings. Заполняем все по аналогии со следующим скриншотом и жмем «ОК».

    Аналогичным нажатием на «ОК» завершаем конфигурацию и PHP Web Application. Если все сделано верно, то можно приступать к пробному запуску. Для этого ставим Breakpoint (по-русски, «точка остановки») и жмем иконку запуска дебаггера.

    Если все сделано верно, то вас перебросит в выбранный браузер, где начнет загрузку страница вида:
    http : //www.angarsky.loc/?XDEBUG_SESSION_START=10098 .
    Буквально сразу у вас замигает иконка PhpStorm на панели Windows. Переходим в PhpStorm и видим следующую картину.

    Теперь более подробно о том, что я отметил маркерами:

    1. Стек функций, который прошел скрипт до нашего Breakpoint’а.
    2. Список переменных, доступных в данной функции в данный момент исполнения кода.
    3. Список переменных для отслеживания . Сюда вы можете перетаскивать все необходимые переменные из второй колонки, значения которых необходимо отследить.
    4. Кнопка остановки отладчика .
    5. Кнопки для навигации в коде: переход на следующую строку кода, переход к следующей точке остановки. Однако я рекомендую работать с горячими клавишами – о них чуть ниже.
    6. Указатель строки текущего состояния отладчика.

    Чтобы выйти из состояния отладки нажмите «F9» . Можете перейти обратно в браузер и убедиться, что страница сайта загрузилось как обычно. Если обновить страницу, то опять сработает дебаггер – это будет происходить до тех пор, пока вы не отключите процесс отладки.

    Управление процессом отладки

    Ниже приведены комбинации горячих клавиш, необходимых для быстрой отладки кода:

    • F7 – переход к следующему шагу кода, выполняя заход во все встречающиеся функции.
    • F8 – переход к следующей строке кода, минуя заход в функции.
    • F9 – переход к следующему Breakpoint’у или завершение процесса отладки при их отсутствии.
    • Shift + F8 – выход из текущей функции.

    Для дальнейшего наглядного примера я поставил Breakpoint в своей кастомной функции, отвечающей за изменение комментариев.

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

    Собственно сейчас отладчик находится на строке 15. Если «шагать» по коду, используя клавишу F7, то вы через два шага вы окажетесь в функции drupal_get_path ( ) . При использовании клавиши F8 функция drupal_get_path ( ) будет выполнена в фоне, а вы сразу окажетесь на строке 18. При нажатии комбинации Shift + F8 вы выйдете из текущей функции и окажитесь в theme ( ) на 1222 строке (см. стек функций). Таким образом, для быстрой отладки необходимо владеть всеми этими приемами.

    Отладка PHP ошибок

    Любой разработчик рано или поздно сталкивается с ошибками в коде. Серьезные ошибки Drupal выводит в сообщениях статуса, предупреждения (PHP warnings) логирует в журнале. Именно для устранения ошибок нам и пригодится отладчик. Для начала выясняем, на каком этапе появляется ошибка (название функции и номер строки) и устанавливаем Breakpoint в данное место. Запускаем отладчик и начинаем поиск ошибки:

    • проверяем все переменные, массивы, объекты;
    • анализируем их изменение в теле функции;
    • переходим на вышестоящие в стеке функции (по клику мыши названию функции в нижнем левом окне по), смотрим, какие данные передаются в текущую функцию;
    • расстанавливаем новые Breakpoint’ы, если это необходимо.

    Устранение ошибок может занять как от нескольких секунд, так до нескольких часов, особенно, если разработчик слабо знаком с архитектурой Drupal . Навык отладки приходит со временем – я, как бы хотел, не смогу объяснить в рамках данного поста все нюансы. Однако дам несколько советов, которые, возможно, позволят сэкономить несколько минут:

    • при установке Breakpoint на массив – размещайте его на строке с первым элементом массива, иначе он не отработает;
    • используйте условные Breakpoint’ы – «Edit» в раскрывающемся меню по левому клику мышки (например, условие «$variables[‘ >);
    • изменяйте файлы ядра, только если у вас подключен Git (или другая система контроля версий) для того, чтобы после отладки без проблем откатить ядро в первозданный вид;
    • для быстрого перехода в функцию используйте клик мышкой по ее названию с зажатой клавишей Ctrl.

    Собственно на этом теория заканчивается и вам пора переходить к практике. Еще раз повторюсь, не переживайте о предстоящем затраченном времени – умение работать с отладчиком вам не раз еще пригодится. Надеюсь, материал окажется хоть для кого-то полезным – уведомьте меня тогда, пожалуйста, об этом в комментариях!

    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL