Удаленная отладка не остановится на точках останова - PullRequest
37 голосов
/ 02 марта 2010

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

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

Ответы [ 21 ]

2 голосов
/ 15 февраля 2013

Я использую Eclipse и тоже некоторое время искал. Все в php.ini было правильно.

В конце я обнаружил, что в Eclipse отладчик был настроен так ZEND-Debugger. После того, как я изменил его на XDEBUG, он работал нормально.

С уважением Йорг

0 голосов
/ 12 марта 2017

Я ненавижу эти конфигурации. Моя жизнь изменилась, когда я узнал lib Dephpugger.

Отладчик для запуска в терминале (например, ipdb для Python и byebug для Ruby). https://github.com/tacnoman/dephpugger Очень прост в использовании.

0 голосов
/ 26 октября 2016

Я не могу комментировать сообщение, поэтому это сообщение.

Решение моей проблемы было очень похоже на pitchandtone. Затмение сделало неправильные и двойные пути картографирования. Тем не менее я мог бы использовать относительные пути (т.е. /project/folder).

0 голосов
/ 06 сентября 2016

Я пытался отлаживать с помощью PhpStorm, но он не остановился на некоторых точках останова и начал игнорировать еще больше, когда я пробовал каждое решение, которое смог найти в Google.

Проблема заключалась в , когда в фоновом режиме выполнялось несколько отдельных PHP-процессов , которые фактически обрабатывали мои запросы. PhpStorm не останавливался на точках останова, потому что процесс, который я отлаживал, не получал запросы. Убийство этих процессов решило это для меня.

0 голосов
/ 20 мая 2016

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

C:\[dev]\OpenServer\domains\...

И я ничего не смог поймать, но после изменения пути проблема исчезла:

C:\dev\OpenServer\domains\...

Так что даже скобки имеют значение.

0 голосов
/ 04 февраля 2015

Когда дело доходит до путей, файловая система OSX не чувствительна к регистру, но xdebug, кажется,

В моем случае все работало, хотя я запускал скрипт, используя /proj/test.php вместо /Proj/test.php.

Когда xdebug (или, по крайней мере, версия, которая у меня есть) проверяет точки останова, проверка чувствительна к регистру. Если точка останова установлена ​​для /Proj/test.php, но скрипт запускается через /proj/test.php, то совпадения нет.

У меня также была похожая проблема с путём включения PHP. Путь включал / proj -directory, что было неверно. Выполнение кода работало, но поскольку точки останова были установлены с помощью / Proj, они не были затронуты.

Чтобы проверить, является ли это проблемой:

  • Включить ведение журнала, -dxdebug.remote_log = / tmp / remote.log
  • Проверьте точный путь в журнале, когда установлены точки останова
  • Сравните путь к используемому PHP-интерпретатору, например: echo dirname (__ FILE__);
0 голосов
/ 09 марта 2014

У меня была похожая проблема, и я наткнулся на сообщение, чтобы решить проблему. Моя html-форма (testform.html) вызывала скрипт php (runQuery.php), и Netbeans не мог сломаться в установленных точках разрыва в моем runQuery.php

После проверки всех параметров конфигурации в php.ini и Netbeans путем поиска на форумах, подобных этому, я обнаружил, что netbeans будет ломаться только на точках останова, если файл индекса для проекта является файлом PHP. Это очень важно, иначе вы потратите часы, пытаясь выяснить, почему не работают точки останова.

В Netbeans зайдите в Файл / Свойства проекта / Запустить конфигурацию и убедитесь, что файл индекса является файлом PHP. В моем случае я изменил свой индексный файл с testform.html на testform.php, и это сработало, я смог разбить точки останова.

0 голосов
/ 18 июля 2010

Я время от времени сталкивался с этим и никогда не мог выяснить истинную причину проблемы.

Я обычно разрешаю,

  1. Размещение дополнительных точек останова в клиентском коде, создание экземпляров и загрузка классов (как кажется, XDebug игнорирует некоторые точки останова из-за проблем с загрузкой классов). Вы можете узнать и понять, где находятся эти места, выполнив несколько шагов.

  2. Проверьте исходные пути зависимостей. XDebug забирает эти файлы по полному пути, вы можете увидеть, как ваша IDE обращается к ним на панели точек останова.

0 голосов
/ 12 марта 2010

Не могли бы вы предоставить полный журнал сеанса при попытке отладки с помощью Web IDE?

Кстати, при использовании Web IDE обычно не требуется устанавливать xdebug.idekey = webide, поскольку ключ ide автоматически назначается через параметр url.

0 голосов
/ 11 апреля 2019

Просто для быстрого обновления предмета у меня была похожая проблема с моей новой установкой 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, и теперь все в порядке.

Надеюсь, это кому-нибудь поможет;)

...