Удаленная отладка не остановится на точках останова
У меня проблема с тем, что xdebug не останавливается на точках останова при использовании удаленной отладки (все нормально при запуске сценариев через командную строку). Он сломается в первой строке программы, затем выйдет, не перехватывая точек останова.
Раньше он работал нормально, пока я не переключился на использование MacPorts для Apache и PHP. Я пытался перекомпилировать его несколько раз (с несколькими версиями), но без игры в кости.
Я использую PHP 5.3.1 и Xdebug 2.1.0-beta3
Я также пробовал как минимум 3 разные программы отладки (MacGDBp, Netbeans и JetBrains Web IDE).
Мои настройки php.ini выглядят так:
[xdebug]
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_port=9000
xdebug.remote_host=localhost
xdebug.idekey=webide
И когда я записываю выходные данные отладчика, установка точки останова выглядит следующим образом /;
<- breakpoint_set -i 895 -t line -f file:///Users/WM_imac/Sites/wm/debug_test.php -n 13 -s enabled
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="895" state="enabled" id="890660002"></response>
При запуске отладчик получит контекст первой строки приложения, затем отправит сообщения отсоединения и остановки.
Однако эта строка выводится при запуске отладчика.
<- feature_get -i 885 -n breakpoint_types
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_get" transaction_id="885" feature_name="breakpoint_types" supported="1"><![CDATA[line conditional call return exception]]></response>
Означает ли что-либо "исключение условного возврата строки"?
20 ответов
У меня была эта проблема, и мне понадобилось много времени, чтобы найти ответ.
В вашей конфигурации отладки в области сервера нажмите Configure, перейдите к Mapping Path, щелкните путь, который там находится, и нажмите edit, перейдите в Path в файловой системе и перейдите к нужному файлу.
Готово.
У меня была та же проблема, и, наконец, я обнаружил, что в моем php.ini отсутствуют следующие два важных параметра:
xdebug.remote_autostart = "On"
xdebug.remote_enable = "On"
Тогда это сработало отлично.
С http://xdebug.org/docs/install: "Вы должны игнорировать любые запросы на добавление" extension =xdebug.so "в php.ini - это вызовет проблемы".
Итак, это исправило это для меня:
в файле конфигурации, где вы загружаете расширение xdebug (для меня, для CLI-версии php, это было /etc/php5/cli/conf.d/xdebug.ini) - не указывайте
расширение =xdebug.so
вместо этого используйте
zend_extension=/ путь / к / Xdebug / модуль / xdebug.so
(для меня это было что-то вроде /usr/lib/php5/(...)/xdebug.so)
XDebug отлично работает в моем Ubuntu Lucid, используя NetBeans, и у меня есть строка zend_extension в моем php.ini (/etc/php5/apache2/php.ini).
Я использую netbeans 6.9 и PHP 5.2 с xdebug 2.0.4-2
Я вставляю соответствующие строки здесь, надеюсь, это поможет:
zend_extension=/usr/lib/php5/20060613/xdebug.so
[debug]
; Remote settings
xdebug.remote_autostart=on
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.idekey="netbeans-xdebug"
; General
xdebug.auto_trace=off
xdebug.collect_includes=on
xdebug.collect_params=off
xdebug.collect_return=off
xdebug.default_enable=on
xdebug.extended_info=1
xdebug.manual_url=http://www.php.net
xdebug.show_local_vars=1
xdebug.show_mem_delta=0
xdebug.max_nesting_level=100
;xdebug.idekey=
; Trace options
xdebug.trace_format=0
xdebug.trace_output_dir=/tmp
xdebug.trace_options=0
xdebug.trace_output_name=crc32
; Profiling
xdebug.profiler_append=0
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=0
xdebug.profiler_output_dir=/tmp
xdebug.profiler_output_name=crc32
У меня была та же проблема, решение для меня было, чтобы локальный код был в том же пути, что и удаленный код.
пример
На веб-сервере код был расположен по пути: /var/www/dev01/app_name
Локально код был расположен в моем домашнем каталоге: /home/me/projects/app_name
Эта конфигурация заставила мою IDE (Eclipse и Komodo) пролететь мимо точек останова.
Изменение локального пути от /home/me/projects/app_name в /var/www/dev01/app_name исправил проблему. Использование sshfs для локального монтирования удаленной файловой системы делает это еще проще.
Я только что испытал нечто похожее на комментарий safl выше, используя Komodo, но не уверен, что это связано:
Я настроил xdebug с помощью zend_extension с Komodo, и он отлично работает, может устанавливать точки останова и xdebug_break(), но только некоторые файлы. Другие не работали.
Решение заключалось в том, как происходило сопоставление удаленных и локальных путей. Оказывается, что Komodo выполняет сравнение по имени пути с учетом регистра, поэтому мое сопоставление не совсем совпадает. Файлы, которые отладчик открыл с помощью пошагового перехода, находились на правильном пути, но файлы, которые я открыл с помощью ide, имели заглавную букву в верхнем регистре, которая, по-видимому, заставляла Комодо не замечать.
Я пробовал все эти решения безрезультатно. Я был сбит с толку, потому что XDebug работал на один из моих проектов, но не на этот новый. Спотыкаясь вокруг сравнения свойств конфигурации, я понял, что на
Свойства проекта> Источники> Корень сети:
значение было установлено в default value на новый проект, но установлен на webroot на существующий проект. Итак, я перешел к webroot проекта и установил это значение. Я проверил это, и, bada-bing, это работало.
Я столкнулся с той же самой вещью и некоторое время стучал головой об нее. В какой-то момент я также добавил ZendDebugger.so в мой PHP.ini, и это было то, что сломало Xdebug. Закомментирование строки ZendDebugger.so в моем php.ini исправило ее.
Если вы не используете ZendDebugger, вы можете просто отключить другие расширения Zend и посмотреть, не является ли это другим расширением, вызывающим конфликт.
У меня такая же проблема. я получил решение, что для загрузки файла DLL мы должны использовать zend_extension.
zend_extension=php_xdebug-2.5.5-5.6-vc11.dll
Остальные настройки будут
xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
Я использую Eclipse и тоже некоторое время искал. Все вещи в php.ini были правы.
В конце я узнал, что в Eclipse отладчик был настроен так ZEND-Debugger, После того как я изменил его на XDEBUG это работало нормально.
С уважением, Йорг
Вы абсолютно уверены, что не загружаете Xdebug через extension=xdebug.so? Xdebug загрузится, если эта строка появится в вашем php.ini (т.е. он появляется в phpinfo() вывод и т. д.), но точки останова не работают, если загружены таким образом. (Он даже подключится к клиентам отладчика и примет точки останова - они просто никогда не сработают.)
Я предлагаю вам закомментировать zend_extension и посмотрите, загружен ли он еще - вы можете подумать, что загружаете Xdebug через /etc/php5/conf.d/xdebug.iniнапример, но что-то добавило его в /etc/php5/apache2/php.ini за твоей спиной.
Смотрите этот вопрос и ответ для получения дополнительной информации.
Не могли бы вы предоставить полный журнал сеанса при попытке отладки с помощью Web IDE?
Кстати, при использовании Web IDE вам обычно не нужно устанавливать xdebug.idekey=webide, так как ключ ide автоматически назначается через параметр url.
В моем случае, когда я перемещаю элемент zend_extension сверху [xdebug] в область ниже [xdebug], он работает хорошо.
;zend_extension = "D:\wamp\bin\php\php5.6.25\ext\php_xdebug-2.5.4-5.6-vc11-
x86_64.dll"
[xdebug]
zend_extension ="D:/wamp/bin/php/php5.6.25/zend_ext/php_xdebug-2.4.1-5.6-vc11.dll"
xdebug.auto_trace = On
xdebug.remote_enable = On
xdebug.remote_autostart = On
xdebug.profiler_enable = On
xdebug.profiler_enable_trigger = On
В моем случае проблема возникала только в одном проекте (мне удалось разорвать только с помощью xdebug_break), в то время как в других проектах все работало нормально.
Исправлено редактирование файла: nbproject / private / private.properties: И установлено:
copy.src.files=false
Когда я создавал проект, я по ошибке выбрал опцию "копировать источники". Затем я вручную переместил проект и отредактировал его исходный путь (в файле "nbproject/project.properties"), который отладчик все еще искал старый путь (заданный в copy.src.target).
Технически, другим способом решения этой проблемы DEBUG является воссоздание каталога nbproject (путем его удаления и повторного создания проекта). Я думаю, что отладчик должен работать нормально с включенной опцией "копировать" (так как я никогда не использую его).
Я надеюсь, что это может помочь.
У меня была похожая проблема, и я наткнулся на сообщение, чтобы решить проблему. Моя html-форма (testform.html) вызывала скрипт php (runQuery.php), и Netbeans не мог сломаться в установленных точках разрыва в моем runQuery.php
После проверки всех параметров конфигурации в php.ini и Netbeans путем поиска на форумах, подобных этому, я обнаружил, что netbeans будет ломаться только в точках останова, если файл индекса для проекта является файлом PHP. Это очень важно, иначе вы потратите часы, пытаясь выяснить, почему не работают точки останова.
В Netbeans перейдите в Файл / Свойства проекта / Запустить конфигурацию и убедитесь, что файл индекса является файлом PHP. В моем случае я изменил свой индексный файл с testform.html на testform.php, и это сработало, я смог разбить точки останова.
Просто для быстрого обновления предмета у меня была похожая проблема с моей новой установкой dev, и это было очевидно проблемой с версией: по крайней мере, с версией PHP 7.1.20-1+ubuntu16.04.1+deb.sury.org+1 xdebug 2.7.1 не работает:
он успешно выполнил первый запрос (я работаю над проектом Symfony, так что это router.php), но затем, когда моя IDE (PHPSTORM) запросила у него другую точку останова, он просто потерпел крах, так что журнал точек останова и, конечно, моя страница тоже не загрузились ^^.
Я понял это, просматривая журнал (в php.ini вы можете настроить его с помощью параметра xdebug.remote_log). Надеюсь, я откатил xdebug до версии 2.6.1, и теперь все в порядке.
Надеюсь, это кому-нибудь поможет;)
Чтобы исправить проблемы с отладкой PHP CLI,
Добавьте переменные окружения в ~/.bashrc (и затем перезагрузите его):
export PHP_IDE_CONFIG="serverName=www.yourservernameurl.com"
export XDEBUG_CONFIG="idekey=PHPSTORM"
(Я использую phpstorm, но вы можете опустить второй по мере необходимости)
Я не могу комментировать пост, поэтому этот пост.
Решение моей проблемы было очень похоже на pitchandtone. Eclipce сделал неправильные и двойные пути картографирования. Тем не менее я мог бы использовать относительные пути (например, /project/folder).
Также могут быть проблемы с необычными символами на пути. Например, мой код находился по пути:
C:\[dev]\OpenServer\domains\...
И я не смог ничего поймать, но после изменения пути проблема исчезла:
C:\dev\OpenServer\domains\...
Так что даже скобки имеют значение.
Я сталкиваюсь с этим время от времени и так и не смог выяснить истинную причину проблемы.
Я обычно разрешаю,
Размещение дополнительных точек останова на клиентском коде, создание экземпляров и загрузка классов (как кажется, XDebug будет игнорировать некоторые точки останова из-за проблем с загрузкой классов). Вы можете узнать и понять, где находятся эти места, выполнив несколько шагов.
Проверьте исходные пути зависимостей. XDebug забирает эти файлы по полному пути, вы можете увидеть, как ваша IDE обращается к ним на панели точек останова.
Я ненавижу эти конфигурации. Моя жизнь изменилась, когда я узнал lib Dephpugger.
Отладчик для запуска в терминале (например, ipdb для Python и byebug для Ruby). https://github.com/tacnoman/dephpugger Очень прост в использовании.
Когда дело касается путей, файловая система OSX не чувствительна к регистру, но, похоже, xdebug.
В моем случае все работало, хотя я запускал скрипт, используя /p roj / test.php вместо /P roj / test.php.
Когда xdebug (или, по крайней мере, версия, которая у меня есть) проверяет точки останова, проверка чувствительна к регистру. Если точка останова установлена для /Proj/test.php, но скрипт запускается через /proj/test.php, то совпадения нет.
У меня также была похожая проблема с путём включения PHP. Путь включал /proj -directory, что было неверно. Выполнение кода работало, но поскольку точки останова были установлены с помощью /Proj, они не были затронуты.
Чтобы проверить, является ли это проблемой:
- Включить ведение журнала, -dxdebug.remote_log=/tmp/remote.log
- Проверьте точный путь в журнале, когда установлены точки останова
- Сравните путь к используемому PHP-интерпретатору, например: echo dirname(__FILE__);
Я пытался отлаживать с PhpStorm, но он не останавливался на некоторых точках останова и начал игнорировать еще больше, поскольку я пробовал каждое решение, которое я мог найти с Google.
Проблема заключалась в том, что в фоновом режиме выполнялось несколько отдельных процессов PHP, которые фактически обрабатывали мои запросы. PhpStorm не останавливался на точках останова, потому что процесс, который я отлаживал, не получал запросы. Убийство этих процессов решило это для меня.
Также убедитесь, что файлы синхронизированы локально и удаленно, иначе ваша точка останова может оказаться в недопустимой области, например, в пустой строке, и она не будет работать.
Также убедитесь, что у вас достаточно разрешений. Я попытался выполнить синхронизацию через NetBeans и получил отказ в разрешении
Также убедитесь, что URL-адрес в вашем браузере установлен правильно после запуска отладчика. В моей папке nbproject был старый URL-адрес.