Xdebug remote host что это

Step Debugging

Xdebug provides an interface for debugger clients that interact with running PHP scripts. This section explains how to set-up PHP and Xdebug to allow this, and introduces a few clients.

Introduction

Xdebug’s (remote) debugger allows you to examine data structure, interactively walk through your and debug your code. The protocol that is being used is open, and is called DBGp. This protocol is implemented in Xdebug 2, and replaces an older GDB-like protocol that is no longer supported.

Clients

The simple command line client dbgpClient for debugging is available on the download page.

Starting The Debugger

In order to enable Xdebug’s debugger you need to make some configuration settings in php.ini. These settings are xdebug.remote_enable to enable the debugger, xdebug.remote_host and xdebug.remote_port to configure the IP address and port where the debugger should connect to. There is also a xdebug.remote_connect_back setting that can be used if your development server is shared with multiple developers.

If you want the debugger to initiate a session when an error situation occurs (PHP error or exception) then you also need to change the xdebug.remote_mode setting. Allowed values for this setting are «req» (the default) which makes the debugger initiate a session as soon as a script is started, or «jit» when a session should only be initiated on an error.

After made all those settings Xdebug will still not start a debugging session automatically when a script is run. You need to activate Xdebug’s debugger and you can do that in three ways:

Using an environment variable

When running the script from the command line you need to set an environment variable, like:

On Windows, setting an environment variable is done with set :

You can also configure the xdebug.remote_host, xdebug.remote_port, xdebug.remote_mode and xdebug.remote_handler in this same environment variable as long as you separate the values by a space:

All settings that you can set through the XDEBUG_CONFIG setting can also be set with normal php.ini settings.

Using a GET parameter

If you want to debug a script started through a web browser, simply add XDEBUG_SESSION_START=session_name as parameter to the URL. Instead of using a GET parameter, you can also set XDEBUG_SESSION_START as a POST parameter, or through a cookie named XDEBUG_SESSION. Refer to the next section to read on how debug sessions work from within a browser window.

Using a browser extension

An alternative way to activate the debugger while running PHP through a web server is by installing one of the following four browser extensions. Each of them allows you to simply enable the debugger by clicking on one button. When these extensions are active, they set the XDEBUG_SESSION cookie directly, instead of going through XDEBUG_SESSION_START as described in HTTP Debug Sessions further on.

The extensions are:

Xdebug Helper for Firefox This extension for Firefox was built to make debugging with an IDE easier. You can find the extension at https://addons.mozilla.org/en-GB/firefox/addon/xdebug-helper-for-firefox/. The source code for this extension is on GitHub. Xdebug Helper for Chrome This extension for Chrome will help you to enable/disable debugging and profiling with a single click. You can find the extension at https://chrome.google.com/extensions/detail/eadndfjplgieldjbigjakmdgkmoaaaoc. XDebugToggle for Safari This extension for Safari allows you to auto start Xdebug debugging from within Safari. You can get it from Github at https://github.com/kampfq/SafariXDebugToggle. Xdebug launcher for Opera This extension for Opera allows you to start an Xdebug session from Opera.

Before you start your script you will need to tell your client that it can receive debug connections, please refer to the documentation of the specific client on how to do this. To use the bundled client simply start it after downloading it. You can start it by running dbgpClient on Linux, dbgpClient-macos on MacOS, and dbgpClient.exe on Windows.

When the debug client starts it will show version information and then waits until a connection is initiated by the debug server (Xdebug):

After a connection is made the output of the debug server is shown:

Now you can use the commands as explained on the DBGp documentation page. When the script ends the debug server disconnects from the client and the debug client resumes with waiting for a new connection. There is a more comprehensive documentation available for Command Line Debug Client as well.

Communication Set-up

With a static IP/single developer

With remote debugging, Xdebug embedded in PHP acts like the client, and the IDE as the server. The following animation shows how the communication channel is set-up:

With an unknown IP/multiple developers

If xdebug.remote_connect_back is used, the set-up is slightly different:

HTTP Debug Sessions

Multiple Users Debugging

Xdebug only allows you to specify one IP address to connect to with xdebug.remote_host) while doing remote debugging. It does not automatically connect back to the IP address of the machine the browser runs on, unless you use xdebug.remote_connect_back.

There are two solutions to this. First of all, you can use a DBGp proxy. For an overview on how to use this proxy, please refer to the article at Debugging with multiple users. You can download the proxy on ActiveState’s web site as part of the python remote debugging package. There is some more documentation in the Komodo FAQ.

Secondly you can use the xdebug.remote_connect_back setting that was introduced in Xdebug 2.1.

Implementation Details

Xdebug’s implementation of the DBGp protocol’s context_names command does not depend on the stack level. The returned value is always the same during each debugger session, and hence, can be safely cached.

Custom DBGp commands

The DBGp protocol allows for debugger engine specific commands, prefixed with the xcmd_ prefix. Xdebug includes a few of these, and they’re documented here.

DBGp: xcmd_profiler_name_get

If Xdebug’s profiler is currently active (See: Profiling), this command returns the name of the file that is being used to write the profiling information to.

DBGp: xcmd_get_executable_lines

The command returns the information in the following XML format:

Related Settings and Functions

Settings

integer xdebug.extended_info = 1 #

Available in Xdebug

Controls whether Xdebug should enforce ‘extended_info’ mode for the PHP parser; this allows Xdebug to do file/line breakpoints with the remote debugger. When tracing or profiling scripts you generally want to turn off this option as PHP’s generated oparrays will increase with about a third of the size slowing down your scripts. This setting can not be set in your scripts with ini_set(), but only in php.ini.

string xdebug.idekey = *complex* #

Controls which IDE Key Xdebug should pass on to the debugging client or proxy. The IDE Key is only important for use with the DBGp Proxy Tool, although some IDEs are incorrectly picky as to what its value is.

The default is based on the DBGP_IDEKEY environment setting. If it is not present, the default falls back to an empty string.

If this setting is set to a non-empty string, it selects its value over DBGP_IDEKEY environment variable as default value.

The internal IDE Key also gets updated through debugging session management and overrides the value of this setting as is explained in the documentation.

string xdebug.remote_addr_header = «» #

Introduced in Xdebug >= 2.4

boolean xdebug.remote_autostart = false #

Normally you need to use a specific HTTP GET/POST variable to start remote debugging (see Step Debugging). When this setting is set to 1, Xdebug will always attempt to start a remote debugging session and try to connect to a client, even if the GET/POST/COOKIE variable was not present.

boolean xdebug.remote_connect_back = false #

Introduced in Xdebug >= 2.1

Please note that there is no filter available, and anybody who can connect to the webserver will then be able to start a debugging session, even if their address does not match xdebug.remote_host.

integer xdebug.remote_cookie_expire_time = 3600 #

Introduced in Xdebug >= 2.1

This setting can be used to increase (or decrease) the time that the remote debugging session stays alive via the session cookie.

boolean xdebug.remote_enable = false #

This switch controls whether Xdebug should try to contact a debug client which is listening on the host and port as set with the settings xdebug.remote_host and xdebug.remote_port. If a connection can not be established the script will just continue as if this setting was 0.

string xdebug.remote_handler = dbgp #

Available in Xdebug

Can only be ‘dbgp’ to represent the debugger protocol. The DBGp protocol is the only supported protocol.

string xdebug.remote_host = localhost #

Selects the host where the debug client is running, you can either use a host name, IP address, or ‘unix:///path/to/sock’ for a Unix domain socket. This setting is ignored if xdebug.remote_connect_back is enabled.

Support for Unix domain sockets was introduced in Xdebug 2.6.

string xdebug.remote_log = #

Configures a file name to log all Step Debugging connection attempts, failures, and communication.

Enable this functionality by setting the value to a absolute path. Make sure that the system user that PHP runs at (such as www-data if you are running with Apache) can create and write to the file.

The file is opened in append-mode, and will therefore not be overwritten by default. There is no concurrency protection available.

When successfully enabled, the log file will include any attempt that Xdebug makes to connect to an IDE:

It includes the opening time ( 2020-06-21 17:54:05 ), the IP/Hostname and port Xdebug is trying to connect to ( localhost:9000 ), and whether it succeeded ( Connected to client 🙂 ). The number in brackets ( [1603325] ) is the Process ID.

It also logs the debugging communication itself, which starts with the XML element:

The fileuri attribute lists the entry point of your application, which can be useful to compare to breakpoint_set commands to see if path mappings are set-up correctly.

Beyond the element, you will find the configuration of features:

The xdebug.remote_log_level setting controls how much information is logged.

Note: Many Linux distributions now use systemd, which implements private tmp directories. This means that when PHP is run through a web server or as PHP-FPM, the /tmp directory is prefixed with something akin to:

integer xdebug.remote_log_level = 7 #

Introduced in Xdebug >= 2.8

Configures which logging messages should be emitted by the Step Debugging.

The following levels are supported:

string xdebug.remote_mode = req #

Selects when a debug connection is initiated. This setting can have two different values:

req Xdebug will try to connect to the debug client as soon as the script starts. jit Xdebug will only try to connect to the debug client as soon as an error condition occurs.

integer xdebug.remote_port = 9000 #

The port to which Xdebug tries to connect on the remote host. Port 9000 is the default for both Xdebug and the Command Line Debug Client. As many clients use this port number, it is best to leave this setting unchanged.

integer xdebug.remote_timeout = 200 #

Introduced in Xdebug >= 2.6

The amount of time in milliseconds that Xdebug will wait for on an IDE to acknowledge an incoming debugging connection. The default value of 200 ms should in most cases be enough. In case you often get dropped debugging requests, perhaps because you have a high latency network, or a development box far away from your IDE, or have a slow firewall, then you can should increase this value.

Please note that increasing this value might mean that your requests seem to ‘hang’ in case Xdebug tries to establish a connection, but your IDE is not listening.

Functions

xdebug_break() : bool #

Emits a breakpoint to the debug client

This function makes the debugger break on the line it is called from, as if a normal file/line breakpoint was set on this line through the debugger protocol.

The function returns true if a debugging session is (now) active, and the breakpoint was succesfully set. It returns false if a debugging session was not active and could not be activated.

xdebug_is_debugger_active() : bool #

Returns whether a debugging session is active

This site and all of its contents are Copyright © 2002-2020 by Derick Rethans.
All rights reserved.

Источник

Отладка с помощью XDebug и PhpStorm (дополнение)

Доброго времени суток, %username%!

Прочитал сегодня статью «Отладка с помощью XDebug и PhpStorm на примере сайта 1С-Битрикс». В ней автор использует «зеленого жука» для запуска отладки. В комментариях предложены еще несколько методов запуска отладки, такие как специальные закладки, различные плагины и т.д. На мой взгляд, все это неудобно, к тому же есть наиболее простой и удобный вариант. Я мог бы предложить его в комментариях к статье, но, увы, в read-only это невозможно. Посему вынужден писать отдельную статью.

У xdebug есть возможность автостарта, без всяких премудростей. Достаточно просто расставить breakpoint’ы и открыть Ваше приложение в браузере, xdebug будет подхватывать старт сам.

1. Настройка XDebug

В php.ini подключаем расширение и устанавливаем параметры:

2. Настройка PhpStorm

Настраиваем интерпретатор, если у вас это еще не сделано.

Далее добавляете сервер, если вы сервер локальный, то пишете в поле Host — localhost, если удаленный то адрес удаленного хоста. Имя хоста здесь и в php.ini должно совпадать.

Настраиваем XDebug. Порт берем из php.ini (xdebug.remote_port). Если вам не нужно чтобы XDebug останавливался на первой строчке приложения, отключаем два нижних чекбокса.

На этом настройка завершена, можно пользоваться.

Использование

Для начала работы расставляете breakpoint’ы, включаете прослушку порта XDebug и открываете ваше приложение.

Breakpoint’ы будут ловиться автоматически, без необходимости тыкать в «зеленого жука». Надеюсь информация кому-нибудь пригодится.

Источник

Отладка PHP приложений на удаленном хосте при помощи XDebug и vim в Linux

Введение

В PHP приложениях отладка при помощи var_dump, debug_backtrace и прочих полезных функций не всегда удобна, и возникает потребность в полноценном отладчике. Эта статья — для тех, кто по каким-либо причинам не хочет использовать IDE, поддерживающие отладку PHP приложений из коробки, вроде NetBeans или PhpStorm, а хочет использовать для этих целей vim, и при этом отладка происходит на удаленном хосте.

Для vim существует плагин «DBGp client», но он позволяет нормально отлаживать только в случае, когда пути до всех файлов на удаленной и на локальной машинах одинаковые. Например, если локальной машине у вас есть:
/home/user/application/
/home/user/framework/
а на удаленной машине они расположены в:
/var/www/html/application/
/var/www/framework/
то отладить приложение при помощи «DBGp client» не получится, так как он ничего не знает о другом расположении исходников.

Установка

Настраиваем vim на локальном хосте

Внимание: vim должен быть собран с поддержкой python, проверить это можно при помощи «:version«, в выводе должна быть строка «+python».

Устанавливаем и настраиваем Xdebug на удаленном хосте

Установите расширение Xdebug любым удобным для вас способом. Например, на Debian Squeeze это делается просто:
# apt-get install php5-xdebug
А в общем случае, лучше почитать официальную инструкцию по установке.

Настройте подключение к локальному debug-клиенту — для этого в php.ini пропишите следующие строчки, заменив 192.168.1.110 на IP локальной машины (при необходимости порт тоже можно перенастроить):
xdebug.remote_enable = 1
xdebug.remote_port = 9000
xdebug.remote_host = 192.168.1.110

Настраиваем соответствие файлов

Идея простая — при отправке запроса дебагеру (например, на установку breakpoint), мы должны преобразовывать путь на локальном хосте в путь на удаленном хосте, и наоборот, при получении информации от дебагера (например, о том что сейчас он находится на какой-то строке какого-то файла), мы должны сделать обратное преобразование.
Дописываем в конец файла debugger.py следующий код:

А в файл mapping (/home/alexey/mapping — замените на свой путь) записываем соответствие локальный и удаленных директорий, например:
/home/alexey/framework /var/www/framework
/home/alexey/application /var/www/html

Просматриваем код плагина в поисках мест, где от Xdebug приходят имена файла. В итоге, все они сводятся к вызову одного метода — set_srcview, в начало которого мы и добавляем изменение имени файла:

Теперь ищем места, где наоборот от debug-клиента к Xdebug передаются имена файлов. Таких мест два:
1. Класс Debugger, метод run, заменяем строку

2. Класс Debugger, метод mark, заменяем строку:

Уже поправленный debugger.py можно взять тут.

Использование

Запускаем отладку

Настройка под себя

Таймаут можно задать в том же скрипте, найдя в debugger.py строку:

Навигация по коду

Просмотр текущего состояния

Установка breakpoints

Toggle breakpoint (:Bp) — установить breakpoint в текущей строке, или удалить, если он уже есть.
На скриншоте — зеленая строка — это строка с breakpoint, красная — это текущая строка:

Источник

Узнать и полюбить Xdebug

Как мне использовать его?

Xdebug поставляется с подробной инструкцией по установке в которой учтены практически все возможные варианты использования, хотя, если вы хотите поэкспериментировать с представленным ниже функционалом, мы рекомендуем использовать Homestead Improved так как там Xdebug установлен и активирован по умолчанию.

Зачем вообще нужен Xdebug когда есть современные IDE и Blackfire?

Современные IDE предоставляют широкие возможности поиска по коду, так что полезность функционала форматирования ссылок кажется сомнительной. Существуют всевозможные системы логирования способные обрабатывать ошибки и исключения. Также, трассировка и профилирование функций прекрасно реализованы в Blackfire. Не смотря на все это, форматирование ссылок на файлы лишь одна из функций Xdebug, а использование Blackfire связано с собственными трудностями — установка расширения, настройка горячих клавиш, и оплата сохранения истории трассировок. А использование логгеров требует внимательности, так как добавить их в приложение на поздних этапах не самая простая задача.

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

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

Давайте попробуем

Предполагается что на этом этапе у вас уже есть среда с работающим Xdebug. Если нет, попробуйте воспользоваться Homestead Improved.

Вот что мы получим:

Отключение Xdebug

Блоки уведомлений подобные этому настолько привычное явление в наше время, что большинство людей даже не понимает что они уже стилизованы с помощью Xdebug. Чтобы доказать это давайте посмотрим как бы это сообщение выглядело без Xdebug. Для отключения Xdebug отредактируем файл /etc/php/7.1/fpm/conf.d/20-xdebug.ini в Homestead Improved, и закомментируем первую строку:

После чего нужно перезапустить PHP-FRM:

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

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

Теперь вновь активируем Xdebug, раскомментировав строку в отредактированном ранее файле, и продолжим. Не забудьте перезапустить PHP!

Переходы по файлам

Если у вас есть любимая IDE (у меня, например, PhpStorm), возможность переходить к файлам в ней простым кликом в трассировке стека была бы определенно полезной и значительно увеличила бы скорость отладки. Я продемонстрирую как реализовать эту возможность для PhpStorm.

Давайте снова откроем файл 20-xdebug.ini и добавим в него следующее:

Заметьте, что не во всех браузерах это будет работать. Например, у Opera возникнут проблемы со ссылкой phpstorm:// и она радостно упадет, в то время как Firefox и Chrome прекрасно обрабатывают такие ссылки.

Если теперь обновить нашу PHP страницу с ошибкой, мы получим ссылки открывающие IDE сразу в точном местоположении ошибки:

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

Xdebug, Vagrant и PhpStorm

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

К счастью, Xdebug отлично поддерживает использование брейк-пойнтов при удаленном соединении. Мы рассмотрели этот процесс выше, а полностью иллюстрированное руководство по настройке вы можете найти в этой статье.

Использование профайлера.

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

И снова нам нужно внести правки в файл 20-xdebug.ini, добавив следующее:

Заметьте — мы не используем xdebug.profiler_enable = 1, так как не хотим чтобы он оставался включенным всё время. Вместо этого мы используем триггерный параметр в запросе “XDEBUG_PROFILE” для выборочной активации. Также мы выводим профиль кэша в основную общую папку нашей виртуальной машины, получая возможность работать с ним в операционной системе хоста.

После перезапуска PHP мы можем проверить это выполнив homestead.app/?XDEBUG_PROFILE (замените homestead.app на имя выбранного вами виртуального хоста или IP-адрес виртуальной машины). Конечно же, файл там где и ожидалось:

В каждой операционной системе есть собственный инспектор кэширования, для OS X, например, можно использовать qcachegring, который легко устанавливается через Homebrew. После установки…

… и открытия файла, мы видим удобное разбиение потока выполнения:

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

Принудительное отображение Xdebug в Laravel

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

Хотя экран ошибок Symfony (который Laravel использует в этом случае) способен так же хорошо работать с переходами Xdebug (попробуйте! Вы можете кликнуть по этим файлам и их строкам!), мне очень не хватает вывода информации о памяти (Xdebug по умолчанию выводит отчет об использовании памяти в каждый момент времени в трассировке). Давайте вернемся к экрану Xdebug в режиме разработки, чтобы отследить этот параметр.

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

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

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

Заключение

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

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

Источник