Introducing xdebug

Автор оригинала: Stefan Priebsch
  • Перевод
Эта статья первая из серии статей, описывающих xdebug, свободной библиотеки для разработчиков PHP. xdebug – это расширение для PHP, написанное Derick Rethans, одним из разработчиков языка PHP. В данной статье описывается как установить xdebug и рассказывается о его базовых возможностях. В последующих частях мы детальнее взглянем на главные возможности xdebug, а именно трассировку, профайлинг, отладку кода.


Установка расширения xdebug
Перво-наперво нам необходимо установить xdebug. Когда была написана эта статья, xdebug был версии 2.0.1. С тех пор PHP APIs могло измениться, вы должны быть уверены, что версия xdebug поддерживается версией PHP, которую вы используете.
xdebug не работает с версиями PHP ниже 4.3, и возможно не будет работать с PHP 6. Но это не есть большая проблема, так как ветка PHP 4 закончила свою жизнь в конце 2007, а PHP 6 возможно не выйдет до конца 2008.

Установка в Unix

До погружения в возможности xdebug, давайте поговорим об установке. В Unix вы можете попробовать установить xdebug из библиотеки расширений PHP. Данный вид установки не работает на всех системах. Если так происходит в вашей системе, вы должны скомпилировать расширение xdebug из исходников. Но в начале попробуйте установку из PECL:
pecl install xdebug

Как было сказано выше, если установка из PECL не работает в вашей системе, вы должны скомпилировать xdebug из исходников. В дополнение к компилятору языка C, у вас должны быть соответствующие версии приложений для сборки (Autoconf, Automake и Libtool). Если их у вас нет, необходимо их установить…
К тому же в PHP есть две необходимые программы phpize и php-config, которые являются частями PHP, они также понадобятся для установки. Если вы не компилировали PHP из исходников, то возможно понадобится установить пакет разработки (php5-dev).
Обратите внимание, что phpize и php-config должны соответствовать используемой версии PHP, поэтому не копируйте их в свою систему из другой. Когда вы убедились, что все необходимые программы присутствуют, вы можете скачать и скомпилировать xdebug:
wget xdebug.org/link.php?url=xdebug201
tar -xzf xdebug-2.0.1.tgz
cd xdebug-2.0.1
phpize
./configure --enable-xdebug --with-php-config=/usr/bin/php-config
make
cp modules/xdebug.so /usr/lib/apache2/modules/xdebug.so

Путь к php-config может быть другим в вашей системе. В зависимости от настроек Apache вы должны скопировать xdebug.so в нужный каталог. Однако вместо копирования файла вы можете создать символическую ссылку на него.

Установка в Windows

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

Активация расширения xdebug

Сейчас у вас есть готовое расширение xdebug, который является либо shared-объектом в Unix или DLL в Windows. Для его активации необходимо добавить запись в php.ini.
Для Windows: zend_extension_ts=«c:\php\ext\php_xdebug-2.0.1-5.2.1.dll»
Для Unix: zend_extension="/usr/lib/apache2/modules/xdebug.so"

Путь к каталогам, в которых находятся расширения PHP и Apache могут быть другими на вашей системе. Убедитесь в том, что вы используете абсолютные пути.
Пожалуйста, обратите внимание, что в примере для Windows мы используем zend_extension_ts, что означает, что загружается потокобезопасное (thread-safe) расширение, в то время как для Unix, мы загружаем непотокобезовпасное расширение. В зависимости от настроек вашей системы, вы должны решать когда вам необходимо то или иное состояние. Если вы не знаете в каком режиме запущен ваш PHP, посмотрите на вкладку Thread Safety в выводе команды phpinfo().
Вы не сможете загружать другие расширения Zend порка работаете с xdebug, потому что они будут использовать тот же внутренний механизм движка Zend, что может привести к проблемам. Не все расширения Zend работают совместно с xdebug. Использовать xdebug предпочтительнее на машине разработчика, чем на продакшене из-за серьезных ограничений. Важное правило не использовать совместно с xdebug другие расширения PHP предназначенные для отладки.
Перестартовав ваш веб-сервер, потому что мы изменили php.ini, посмотрите вывод команды phpinfo() или запустите php -m в командной строке. В каждом из случаев, xdebug должен быть выведен дважды, один раз как расширение PHP, другой раз как расширение Zend



Будьте осторожны при обновлении PHP с установленным xdebug. Если поменяется внутреннее APIs в версиях PHP, новая версия PHP возможно не запустится или покажет странные ошибки. Если такое произойдет, временно отключите xdebug, дождитесь более новой версии PHP и xdebug и включите xdebug снова.
Для конфигурации xdebug существует несколько переключателей в php.ini, большинство из них имеет разумные значения по умолчанию, поэтому вы не должны беспокоиться о конфигурации xdebug. Мы рассмотрим самые важные параметры конфигурации.

Улучшенный вывод var_dump()

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



Вы можете настроить как именно xdebug должен формировать вывод функции var_dump() с помощью различных настроек в php.ini. Во-первых, вы можете изменить длину выводимой строки. Значение по умолчанию 512; более длинные строки обрезаются автоматически.
В зависимости от того выводить ли полностью строку или нет, зависит от ситуации и данных, с которыми вы работаете. Если вы работаете с большими строками, вывод функции var_dump() может быть слишком длинным и трудно читаемым, поэтому идея укорачивания строки выглядит достаточно приятной. В противоположность, если вы работаете со специфическими значениями, вы, скорее всего, заходите увидеть значение полностью.
Для изменения длины строки выводимой xdebug добавьте
xdebug.var_display_max_data=
в php.ini и перезапустите ваш веб-сервер. В качестве альтернативы, вы можете изменить эту настройку в своем скрипте используя функцию ini_set, вы можете добавить
ini_set('xdebug.var_display_max_data', );
в начале вашего скрипта. Проверьте, чтобы вызов ini_set был до первого вызова var_dump(). Конфигурация xdebug во время выполнения избавит вас от перезапуска веб-сервера каждый раз когда вы меняете php.ini и позволит более гибко его настраивать.
Вы также можете контролировать количество элементов массива и свойств объектов, которых будет выводить xdebug. Этого можно достигнуть модифицируя xdebug.var_display_max_children (значение по умолчанию 128). Этого значения будет вполне достаточно для отображения свойств вашего объекта, но если вы работаете с массивами, может быть необходимо увеличить значение…
Если вы работаете с вложенными объектами или массивами, вы можете модифицировать xdebug.var_display_max_depth. Эта настройка имеет значение по умолчанию 3, значит, что отобразиться три измерения в массиве и три уровня вложенности в объекте.
Вы также можете вывести значения суперглобальных переменных, используя функцию xdebug_dump_superglobals(). Так как суперглобальные массивы, особенно $_SERVER, — это массивы, содержащие большое количество значений, вы должны явно указать xdebug какой ключ массива вы хотите видеть. Чтобы сделать это установите xdebug.dump., где это один из следующих имен GET, POST, SERVER, COOKIE, FILES, REQUEST или SESSION. Используйте ключи массивов, которые вы хотите вывести с помощью xdebug в качестве аргументов, если вы хотите выводить несколько значений, то перечислите их через запятую. Вы можете использовать * как шаблон для отображения ключей, который может особенно полезен для вывода $_GET и $_POST.
Используйте
ini_set('xdebug.dump.SERVER', 'HTTP_HOST, SERVER_NAME')

в вашем PHP скрипте или настройки xdebug.dump.SERVER=HTTP_HOST, SERVER_NAME в php.ini для отображения значений $_SERVER['HTTP_HOST'] и $_SERVER['SERVER_NAME']. Для отображения всех значений GET, которые были переданы в скрипт, используйте
xdebug.dump.GET=*




По умолчанию xdebug не выводит неопределенные (undefined) переменные. Для того чтобы все же отображать неопределенные переменные, установите параметр xdebug.dump_undefined в On. Я советую установить этот параметр в on.

Более красивые сообщения об ошибках

xdebug также улучшает отображение ошибок в PHP автоматически отображая стек вызовов рядом с каждым сообщением об ошибке или предупреждением. Это список вызовов отображает историю вызова функций до момента возникновения сообщения об ошибке. В то время как программы на PHP становятся все более и более объектно-ориентированными, ошибки чаще всего случаются глубоко внутри библиотек. Список вызовов позволит вам быстро найти тот кусочек кода, в котором произошла ошибка, и откуда этот кусочек был вызван.
С версии 5.0 в PHP появилась функция debug_print_backtrace(), которая отображает список вызовов функций, но вы не можете вызвать эту функцию явно, всякий раз когда возникнет ошибка, что означает необходимость создания своего обработчика ошибок. Список вызовов, созданный xdebug, легко читаем в отличие от вывода функций PHP.
Подобно PHP, xdebug выводит ошибки только тогда, когда параметр display_erorrs установлен в On в php.ini.



Посмотрите на этот список вызовов, вы увидите, что сначала была вызвана функция foo(), затем bar(), затем baz(). В дополнение к именам вызываемых функций и места нахождения в исходном коде, xdebug выводит время и количество памяти используемые скриптом в момент вызова этих функций.
Выше, мы уже научились как настраивать xdebug чтобы отображать значения суперглобальных переменных. В дополнение вы можете настроить xdebug чтобы выводить текущие значения локальных переменных. Для того чтобы отображать значения локальных переменных при возникновении сообщения об ошибке необходимо добавить следующую строку
xdebug.show_local_vars=1

в php.ini. Вы также можете использовать ini_set.



Итак, параметры php.in xdebug.var_display_max_data, debug.var_display_max_children и xdebug.var_display_max_depth, которые мы использовали выше для форматирования вывода команды var_dump() также влияют на формат вывода ошибок.
С помощью параметра xdebug.collect_params, вы можете настроить вывод информации о параметрах, которые передаются в функции. xdebug.collect_params имеет числовое значение: 0 – значит отсутствие информации, а 4 означает отображение названий переменных и полной информации по всем параметрам функций. Также доступны значения от 1 до 3, означающие различную детализацию в выводе отладочной информации.



Здесь приведена конфигурация используемая для вывода скриншота:
xdebug.show_local_vars=On
xdebug.dump.SERVER=HTTP_HOST, SERVER_NAME
xdebug.dump_globals=On
xdebug.collect_params=4

Обратите внимание, что чем больше информации вы просите собрать для вас xdebug, тем больше памяти он будет потреблять, и тем больше будет время выполнения. Проверьте, что используете xdebug только для разработки, а не на боевых серверах. Неправильно использовать сообщения об ошибках в формате HTML на боевых серверах, не есть хорошо выводить информацию по логину и паролю к БД в том случае, если у вас не определена переменная .
В то время как суперглобальные переменные не изменяются во время выполнения (примечание переводчика – странное утверждение, видел достаточно много скриптов, в которых происходило их изменение, но не будем обсуждать это в контексте данной статьи), xdebug по умолчанию выводит их только вовремя первого возникновения сообщения об ошибке. Если вы хотите повторять их вывод каждый раз, воспользуйтесь следующей настройкой
xdebug.dump_once=Off

Обращаю внимание на то, что расширенный вывод сообщений об ошибках не работает, если вы определили собственный обработчик ошибок, используя register_error_handler(), все происходит из-за то, что xdebug использует тот же внутренний механизм. Если же вы хотите использовать собственный обработчик ошибок вы можете воспользоваться функцией xdebug_get_function_stack() для вывода списка вызова функций.
Объектно-ориентированный подход использует исключения. Так как исключения это не ошибки, xdebug не выводит список вызовов, если случилось исключение, за исключением тех случаев, когда такое исключение не перехватывается. Неперехваченное исключение это фатальная ошибка. Для того чтобы видеть вызов функций во время появления исключений используйте
xdebug.show_exception_trace=On


Лимит рекурсии

Другая полезная особенность это ограничение шагов рекурсии, которая предотвращает бесконечную последовательность рекурсивных вызовов.
xdebug предотвращает бесконечную рекурсию останавливая скрипт на предопределенном шаге. В принципе это есть ограничение размера стека вызовов. Значение по умолчанию данного параметра 100, и эта возможность включена по умолчанию. Вы можете изменить настройку, если ваша программа подразумевает более глубокую рекурсию.
xdebug.max_nesting_level=
Однако xdebug не предотвращает бесконечные циклы for, while и похожие на ни, так как они не увеличивают стек вызовов. В дополнение вы можете использовать счетчик внутри каждого цикла и убивать скрипт всякий раз, когда значение счетчика превысит допустимую цифру. Я советую использовать данный подход на боевых серверах, потому что там не должно быть бесконечных циклов.
Заключение

xdebug это маленький, но очень полезный инструмент для разработчика PHP, он должен быть установлен на каждую установку PHP, используемую для разработки. Не стоит использовать xdebug на боевых серверах, так как это мешает производительности.
Следующая статья будет посвящена Tracing PHP Applications with xdebug и будет переведена где-то в конце этой недели.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 60

    +3
    Добавлю, что для пользователей Fedora Linux (и прочих основаных на yum) для установки достаточно команды:

    yum -y install php-pecl-xdebug

    Не уверен, но думаю для Убунту и apt-get-дистров достаточно строчки

    apt-get -y install php-pecl-xdebug
      0
      указанное вами для Ubuntu не помогает (даже если убрать -y)
      0
      sudo apt-get install php5-xdebug
        0
        emerge dev-php5/xdebug
        :)
        0
        Для [К]убунту 7.10:
        sudo apt-get install php5-dev
        pecl install xdebug

        Если хочется отлаживать скрипты на Eclipse, нужно ручками подправить путь в /etc/php5/conf.d/xdebug.ini:
        zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so
          0
          Сохранил на память на http://www.xdebug.ru
          0
          Спасибо за статью. Со всем уважением, «ваш веб-мервре» наверное «ваш веб-сервер» (я просто очень хорошо вижу опечатки).
            0
            спасибо. Писал перевод в ворде, вроде смотрел чтобы все было правильно. Но в конце забыл нажать проверку орфографии
              +1
              опечаток немеряно :)))
                0
                все исправил :-)
                  0
                  Вообще перевод какой-то деревянный маненько :) "В зависимости от того выводить ли полностью строку или нет, зависит от ситуации и данных, с которыми вы работаете" и пр и пр.
                    0
                    а что вам тут не понравилось :-)
                    ну можно было данные в этой строке опустить, согласен
                      0
                      "В зависимости зависит" :)
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      "Однако xdebug не предотвращает бесконечные циклы for, while и похожие на ниХ, "
                +1
                В принципе неплохая познавательная статья, но а почему бы маленький обзор/cравнение по дебаггерам для php не сделать ;)?
                Например очень неплох PHP DBG Listener... Прекрасная "оболочка", правда немного тормознутый, но в общем очень неплох.
                Я понимаю кто как хочет так и ... работает. Но можно было бы еще парочку привести для примера... :)
                  0
                  может в следующий раз
                    0
                    хорошая мысль про обзор альтернативных вариантов, кстати ;)
                    +1 за PHP DBG Listener. будет время- попробую.
                      0
                      ещё +1
                      сам пользюсь PHP DBG Listener
                      0
                      Особенно "неплох" PHP DBG Listener вместе с редактором-оболочкой PHP Expert Editor (это не реклама, и никакого отношения к Кременчугской (кстати "наши") Ancord Development Group не имею). Ребята молодцы - сделали отличную оболочку. Советую всем посмотреть. Кстати для стран СНГ - бесплатна! (опять же им большой плюс и спасибо)
                      http://www.ankord.com/ru/index.html
                      +2
                      Очень важная возможность
                      xdebug.profiler_output_dir = "путь к директории "
                      xdebug.profiler_enable = 1
                      - документация http://xdebug.org/docs/profiler
                      + Утилиты для просмотра файлов
                      http://kcachegrind.sf.net/ - Linux
                      href="http://sourceforge.net/projects/wincachegrind/ - Windows
                        +1
                        обзор утилит для отладки, профайлинга смотрите в следующих сериях переводов
                        0
                        Статья неплохая, только вот странно что обзор утилит для анализа не включили в неё, лучше бы всё в одном чем сериал делать :)

                        Вкратце - Lunux-овая версия обладает куда большими возможностями, чем виндовая.
                          0
                          > Но это не есть большая проблема, так как ветка PHP 4 закончит свою жизнь в конце 2008

                          Ну да, конечно. Весь код рассыпется на биты и сайты входящие в Alexa top50 превратятся в тыквы.
                            0
                            http://www.php.net/downloads.php#v4
                            Support for PHP 4 has been discontinued since 2007-12-31. Please consider upgrading to PHP 5.2. The release below is the last PHP 4 release.
                              +1
                              Так в конце 2007-го или в конце 2008-го ? Или может, 2009-го ? ;-)
                                0
                                спасибо за замечание, поправил перевод.
                                Переводчик - балбес :-)
                                  –1
                                  Спасибо в карму не положишь ;-)
                                    0
                                    Я вам сообщение + помечу :-)
                                    0
                                    в 2008 заканчивается выпуск критических дополнений
                              0
                              Пользуюсь xdebug уже давно, ещё есть много программ, которые достойно структуризируют его логи.
                              0
                              прошу совет:
                              сейчас, как и все время до того, я пользуюсь Zend 5.5 + ZendDebugger. производительность етой связки боле-менее меня устраивает сейчас (при переходе на двухядерник). проблема вот в чем: использовал я некоторое время Zend "Neon" 6.0 + ZendDebugger и бил неприятно удивлен падением скорости отладки в нем... в чем же проблема? может поставить то xdebug и настроить его так? кто нить может сравнит ети два отладчика?

                              почему спрашиваю:
                              Zend 6.0 уж больно удобен...
                                0
                                Посмотрите в сторону PDT
                                  0
                                  после Zend 6 как-то трудно ето сделать...
                                  0
                                  XDebug к Zend Neon по идее прикручивается, но как — хз. В комментах к оригинальной статье про отладку на Zend.com кто-то обещал написать, как это сделать, но воз и ныне там.
                                  З.Ы. На форумах у зенда — тишина.
                                  Похоже, будет как в анекдоте про мышек и кактус.
                                    0
                                    воопщем есть плагин к Notepad++ & XDebug...
                                    + тулбар для ФФ...

                                    но мне как-то не по душе пришлось ето...
                                    0
                                    Хорошое описание. Не хватает к статье только профайлера, так как это очень важная часть в оптимизации кода.
                                    Из рекоммендаций: var_display_max_depth лучше ставить не больше 3.
                                      0
                                      в следующих сериях. Профайлер будет в третьей части
                                      0
                                      Может вы знаете, кстати, как настроить взаимодействие IDE (NuSphere) PHPed и XDebug для remote debugging'a?
                                      Родной для IDE-шки DBG, конечно, работает, но хотелось бы любимый XDebug использовать в связке.
                                        0
                                        я погуглил и везде вроде пишут, что все работает
                                        может попробовать скачать новую версию phped
                                          0
                                          я тоже гуглил, что работает, но вот не удалось состыковать :( хотя версия phped одна из последних (5223). ок, здесь в коментах не место для обсуждения этого.
                                        0
                                        За факт перевода спасибо, как раз что надо.

                                        А над фразами типа "если случилось исключение, за исключением тех случаев, когда такое исключение не перехватывается" ещё надо поработать.
                                          +2
                                          буду стараться, там еще 4 статьи про xdebug
                                            0
                                            зачОт))
                                          0
                                          Спасибо за перевод! Посмотрим что за зверь такой=)
                                            0
                                            "библиотеки для разработчиков PHP"

                                            по русски они называются "разработчики _на_ PHP"
                                              0
                                              по русски они называются php-программисты, "разработчики на PHP" - это никак не по русски
                                              –1
                                              А где ссылка на оригинал?

                                              В статье есть ошибки, например "display_erorrs".

                                              Сейчас решил протестировать xdebug. Хз почему, но сразу подумал: "Наверняка ${$foo} не поймёт...". В результате был удивлён тем, то xdebug действительно этого не понял :)
                                                0
                                                attention=On - ссылка на оригинал там же где и баллы за статью, читайте внимательно
                                                где ошибка в display_erorrs?
                                                  0
                                                  А две буквы rr, нашли к чему цепляться.
                                                  Это опечатка при наборе
                                                    0
                                                    Я тоже иногда пишу erorRs, когда быстро печатаю, но дело в том, что статья предназначена для начинающих и такие ошибки могут привести к неточностям в понимании.
                                                      0
                                                      Немного повредничаю: Как часто начинающие (да и все остальные) лазают в php.ini?
                                                  0
                                                  пипль, не хочу выглядить жлобом, но хотелось бы писать статьи по теме РНР, ООА, ООП и т.п. хотя бы в персональный блог, благо опыт позволяет делиться информацией, но хаброкарма счастия сего не дает, посему и обращаюсь к вам, как к участникам сего блога - уж вы то поймете :)

                                                  качество материала можно посмотреть тута: http://blog.azazel.org.ua/index.php?s=php
                                                    0
                                                    ну есть какой-то пост, где можно попросить надбавить кармы
                                                    плюсану вас, только не пишите в блог php про посудомойку :-)))

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое