Как использовать XDebug и vim, когда соединение «потрачено впустую» по предварительному неинтересному вызову сервера
Я использую vim с Vdebug плагин и Xdebug для отладки сервера WebDAV экземпляр следующего облака. Nextcloud использует SabreDAV, поэтому сервер WebDAV представляет собой PHP-скрипт. Клиент синхронизации файлов рабочего стола (OwnCloud) который использует nextcloud, синхронизирует локальную папку с веб-хранилищем nextcloud.
Я хочу отладить проблемы с вычислением квоты сервера nextcloud при загрузке файла WebDAV (предположительно PUT) запрос. Тем не менее, клиент owncloud отправляет несколько запросов WebDAV на сервер, если изменяется локальный файл, где первый (-ие) запрос (-ы) для меня не важен (предположительно, PROPFIND или похожие). Только после этого неинтересного запроса отправляется запрос на загрузку. Однако, если я настрою vim для прослушивания входящего соединения с помощью Xdebug (:VdebugStart), первый неинтересный запрос WebDAV устанавливает соединение, но я хотел бы установить соединение для последующих входящих соединений Xdebug. Однако я не достаточно быстр, чтобы перевести vim в режим прослушивания, прежде чем клиент owncloud снова вызовет сервер с интересным WebDAV-запросом.
Там может быть два способа борьбы с этим:
- Заставьте vim прослушивать новое соединение с Xdebug очень быстро после того, как закончится первое (неинтересное) соединение
- Сделайте так, чтобы PHP не устанавливал соединение Xdebug с самого начала, но только при вызове определенного блока кода, который соответствует интересному запросу на загрузку клиентом. Я мог бы вставить некоторую функцию PHP
xdebug_connect_now_to_client()функция вместо подключения Xdebug к vim с самого начала.
Знаете ли вы возможность для достижения одной из этих целей, или есть другое решение?
Соответствующий php.ini записей:
zend_extension=xdebug.so
xdebug.remote_enable=on
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
; have to set this, because owncloud does not set the
; XDEBUG_START_SESSION=true GET parameter
xdebug.remote_autostart=on
xdebug.idekey=netbeans-xdebug
Решение
Как и вы, я столкнулся с этой проблемой, отлаживая запросы WebDav в NextCloud с помощью xdebug и vdebug.
Мне нравится предложение LazyOne выше, чтобы кодировать в точке останова.
То, что я в итоге сделал, было установить
xdebug.remote_autostart=0
и максимально использовать аддон ниже, чтобы разрешить отладку только для моего запроса.
https://addons.mozilla.org/en-US/firefox/addon/xdebug-helper-for-firefox/
Я также нашел полезным сначала включить трассировку, чтобы получить хоть какое-то представление о том, где в коде мне нужно было искать, что также может помочь вам установить ручную точку останова. Здесь снова вы можете использовать аддон, чтобы минимизировать запросы, которые будут генерировать трассировку.
xdebug.remote_log=/tmp/xdebug_remote.log
xdebug.trace_options=1
# Write a trace file per process
xdebug.trace_output_name=trace.%p
# Only trace if we get XDEBUG_TRACE
xdebug.auto_trace=0
xdebug.trace_enable_trigger=1
Я использую php-fpm, я также установил
; Choose how the process manager will control the number of child processes.
; Possible Values:
; static - a fixed number (pm.max_children) of child processes;
pm = static
так что нет тонны процессов создания файлов трассировки и выдачи запросов
Другие решения
Других решений пока нет …