Удаленная отладка не остановится на точках останова

Question

У меня проблема с тем, что 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>

Значит ли что-нибудь «исключение возврата условного вызова строки»?

Answer 1

У меня была эта проблема, и мне потребовались годы, чтобы найти ответ.

В вашей конфигурации отладки, в области сервера, нажмите Configure, перейдите к Mapping Path, щелкните путь, который там есть, и нажмите edit, измените путь в File System и перейдите к нужному файлу.

Готово.

Answer 2

У меня была такая же проблема, и, наконец, я обнаружил, что в моем php.ini отсутствуют следующие два важных параметра:

xdebug.remote_autostart = "On"
xdebug.remote_enable = "On"

Тогда все заработало отлично.

Answer 3

XDebug прекрасно работает в моем Ubuntu Lucid box, используя 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

Answer 4

из 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)

Answer 5

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

Пример

На веб-сервере код находился по пути: /var/www/dev01/app_name

Локально код находился в моем домашнем каталоге: /home/me/projects/app_name

Эта конфигурация заставила мою IDE (Eclipse и Komodo) пролететь мимо точек останова.

Изменение локального пути с /home/me/projects/app_name на /var/www/dev01/app_name устранило проблему. Использование sshfs для локального монтирования удаленной файловой системы делает это еще проще.

Answer 6

Я только что столкнулся с чем-то похожим на комментарий safl выше, используя Komodo, но не уверен, связано ли это:

Я настроил xdebug с помощью zend_extension с Komodo, и он отлично работает, может устанавливать точки останова и xdebug_break (), но только некоторые файлы. Другие не работали.

Решение было в том, что произошло сопоставление удаленного и локального путей. Оказывается, что Komodo сравнивает имена путей с учетом регистра, поэтому мое сопоставление не совсем совпадает. Файлы, которые отладчик открыл с помощью пошагового перехода, находились на правильном пути, но файлы, которые я открыл с помощью ide, имели заглавную букву в верхнем регистре, которая, по-видимому, заставляла Комодо пропускать.

Answer 7

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

Свойства проекта> Источники> Корень сети:

для нового проекта было установлено значение default value, а для существующего проекта - webroot. Итак, я перешел к webroot проекта и установил это значение. Я проверил это, и, bada-bing, это сработало.

Answer 8

Вы абсолютно уверены, что не загружаете Xdebug через extension=xdebug.so? Xdebug будет загружаться, если эта строка появится в вашем php.ini (то есть она появится в выводе phpinfo() и т. Д.), Но точки останова не будут работать при такой загрузке. (Он даже будет подключаться к клиентам отладчика и принимать точки останова - они просто никогда не сработают.)

Я предлагаю вам закомментировать строку zend_extension и посмотреть, по-прежнему ли она загружена - вы можете подумать, что вы загружаете Xdebug, например, через /etc/php5/conf.d/xdebug.ini, но что-то добавило его в /etc/php5/apache2/php.ini за вашей спиной.

См. этот вопрос и ответ для получения дополнительной информации.

Answer 9

У меня тоже такая же проблема. я получил решение, что для загрузки файла 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

Answer 10

Я столкнулся с той же самой вещью и некоторое время стучал головой об нее. В какой-то момент я также добавил ZendDebugger.so в мой PHP.ini, и это было то, что сломало Xdebug. Закомментирование строки ZendDebugger.so в моем php.ini исправило ее.

Если вы не используете ZendDebugger, вы можете просто начать отключать другие расширения Zend и посмотреть, не является ли это другим расширением, вызывающим конфликт.