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

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

Готово.

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

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

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

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 

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

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

пример

На веб-сервере код находился на пути: /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 по default value для нового проекта, но установлено значение webroot для существующего проекта. Итак, я просмотрел веб-сайт проекта и установил его значение. Я тестировал его и, бада-бинг, он работал.

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

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

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

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

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

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

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

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

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

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

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

Обычно я решаю,

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

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

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

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

 copy.src.files=false 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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