Ответ 1

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

В вашей конфигурации отладки в области сервера нажмите "Настроить", перейдите в "Отображение маршрутов", щелкните путь, который есть там, и нажмите "Изменить", выберите "Путь" в файловой системе и перейдите к нужному файлу.

Готово.

Ответ 2

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

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

Тогда он работал отлично.

Ответ 3

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

Ответ 4

from http://xdebug.org/docs/install, "Вы должны игнорировать любые подсказки, чтобы добавить" extension = xdebug.so "в php.ini - это приведет к проблемы".

Итак, это исправило это для меня:

в файле конфигурации, где вы загружаете расширение xdebug (для меня, для версии CLI версии php, которая была /etc/php 5/cli/conf.d/xdebug.ini) - не указывайте

расширение = xdebug.so

используйте

zend_extension =/путь/к/Xdebug/модуль/xdebug.so

(для меня это было что-то вроде/usr/lib/php5/(...)/xdebug.so)

Ответ 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 для локального монтирования удаленной файловой системы делает ее еще проще.

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

Подробнее см. этот вопрос и ответ.

Ответ 9

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

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

Ответ 10

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

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

Отношения Йорг

Ответ 11

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

Ответ 12

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

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

Ответ 13

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

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

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

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

Ответ 14

В моем случае проблема происходила только в одном проекте (я смог разбить только с помощью xdebug_break), в то время как в других проектах работала нормально.

Исправлено редактирование файла: nbproject/private/private.properties: И установите:

copy.src.files=false

Когда я создал проект, я выбрал опцию "копировать источники" по ошибке. Затем я вручную переместил проект и отредактировал его исходный путь (в файле "nbproject/project.properties" ), который отладчик все еще искал старый путь (установлен в copy.src.target).

Так технически, другой способ исправить эту проблему DEBUG - это воссоздать каталог nbproject (удалив его и снова создав проект). Я думаю, отладчик должен работать нормально с включенной опцией "copy" (поскольку я никогда не использую ее).

Надеюсь, это поможет.

Ответ 15

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

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

В Netbeans зайдите в File/Project Properties/Run Configuration и проверьте, что файл Index является файлом PHP. В моем случае я изменил свой индексный файл с testform.html на testform.php, и он сработал, я смог сломать точки останова.

Ответ 16

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

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

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

У меня также была аналогичная проблема с PHP include path. Путь включал /proj -каталог, что было неправильно. Запуск кода работал, но поскольку точки останова были установлены с использованием /Proj, они не пострадали.

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

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

Ответ 17

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

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

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

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

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

Ответ 18

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

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

Ответ 19

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

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

Ответ 20

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

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

Ответ 21

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

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

Ответ 22

В моем случае, когда я перемещаю элемент 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