リモートデバッグがブレークポイントで停止しない
リモートデバッグを使用しているときにxdebugがブレークポイントで停止しないという問題があります（コマンドラインからスクリプトを実行する場合はすべて問題ありません）。プログラムの最初の行でブレークし、ブレークポイントをキャッチせずに終了します。
以前は、ApacheとPHPにMacPortsを使用するように切り替えるまでは問題なく動作していました。私はそれを（いくつかのバージョンで）何度か再コンパイルしようとしましたが、ダイスはありませんでした。
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>
「ライン条件付き呼び出し戻り例外」は何か意味がありますか？
私にはこの問題があり、答えを見つけるのに何年もかかりました。
デバッグ構成のサーバー領域で、[構成]をクリックし、[パスマッピング]に移動し、そこにあるパスをクリックして[編集]をクリックし、[ファイルシステムのパス]に変更して、正しいファイルに移動します。
できました。
私は同じ問題を抱えていましたが、最終的に私のphp.iniには次の2つの重要な設定がないことがわかりました。
xdebug.remote_autostart = "On"
xdebug.remote_enable = "On"
その後、完全に機能しました。
XDebugは、NetBeansを使用して私のUbuntu Lucidボックスで正常に動作し、php.ini（/etc/php5/Apache2/php.ini）にzend_extension行があります。
私はnetbeans 6.9とPHP 5.2 with 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
from http://xdebug.org/docs/install 、 "php.iniに" extension = xdebug.so "を追加するためのプロンプトはすべて無視する必要があります。これにより問題が発生します。"
だから、これは私のためにそれを修正しました：
xdebug拡張機能をロードする構成ファイル内（私にとっては、phpのCLIバージョンでは/etc/php5/cli/conf.d/xdebug.iniでした）-指定しないでください
extension = xdebug.so
代わりに、使用
zend_extension =/path/to/xdebug/module/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を使用してリモートファイルシステムをローカルにマウントすると、さらに簡単になります。
私はKomodoを使用して上記のsaflのコメントに似たものを経験しましたが、それが関連しているかどうかはわかりません：
私はKomodoでzend_extensionを使用してxdebugをセットアップしましたが、完全に機能し、ブレークポイントとxdebug_break（）を設定できますが、一部のファイルのみです。その他は機能しませんでした。
解決策は、リモートパスとローカルパスのマッピングが発生する方法にありました。コモドはパス名で大文字と小文字を区別する比較を行っていることが判明したため、私のマッピングは完全には一致しませんでした。デバッガーがステップ実行から開いたファイルは正しいパスにありましたが、IDEから開いたファイルには大文字のドライブレターがあり、Komodoが見落としているようでした。
私はこれらの解決策をすべて試しましたが、役に立ちませんでした。 XDebugが私のプロジェクトの1つで機能したが、この新しいプロジェクトでは機能しなかったため、混乱しました。構成プロパティの比較を偶然見つけた後、私はそれを理解しました
プロジェクトプロパティ>ソース> Webルート：
値は、新しいプロジェクトではdefault valueに設定されましたが、既存のプロジェクトではwebrootに設定されました。そこで、プロジェクトのwebrootを参照してその値を設定しました。私はそれをテストしました、そして、それはうまくいきました。
私も同じ問題を抱えています。私は、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
私はこれとまったく同じことに遭遇し、しばらく頭を叩いていた。ある時点で、PHP.iniにZendDebugger.soも追加しましたが、それがXdebugを壊していました。私のphp.iniのZendDebugger.so行をコメント化すると修正されました。
ZendDebuggerを使用していない場合は、他のZend拡張機能を無効にして、競合の原因となっている別の拡張機能であるかどうかを確認してください。
私はEclipseを使用しており、しばらく探しました。 php.iniのすべてが正しい。
最後に、Eclipseの場合デバッガーがZEND-Debuggerに設定されていることがわかりました。 XDEBUGに変更した後、問題なく動作しました。
よろしく
_extension=xdebug.so_経由でXdebugをロードしていないことを完全に確信していますか？この行が_php.ini_にある場合（つまり、phpinfo()出力などにある場合）、Xdebugは読み込まれますが、この方法で読み込まれた場合、ブレークポイントは機能しません。 （デバッガクライアントに接続し、ブレークポイントを受け入れます-トリガーされることはありません）。
_zend_extension_行をコメント化して、まだ読み込まれているかどうかを確認することをお勧めします。たとえば、_/etc/php5/conf.d/xdebug.ini_を介してXdebugを読み込んでいると思われるかもしれませんが、何かが_/etc/php5/Apache2/php.ini_の後ろに追加していますあなたの背中。
詳細は this question＆answer を参照してください。
私は投稿にコメントできないので、この投稿。
私の問題の解決策は、pitchandtoneが言ったようにとてもよくありました。 Eclipceは間違ったダブルパスマッピングアイテムを作成していました。それにもかかわらず、相対パスを使用することができます（つまり、/ project/folder）。
私はPhpStormでデバッグしようとしていましたが、いくつかのブレークポイントで停止せず、Googleで見つけたすべてのソリューションを試していたため、さらに無視し始めました。
問題はデタッチされた複数のPHPプロセスがバックグラウンドで実行されていた実際にリクエストを処理したことです。デバッグしているプロセスがなかったため、PhpStormはブレークポイントで停止しませんでした。 tリクエストを受信しますこれらのプロセスを強制終了すると解決しました。
デバッグの問題を修正するにはPHP CLI、
〜/ .bashrcに環境変数を追加します（後で再読み込みします）。
export PHP_IDE_CONFIG="serverName=www.yourservernameurl.com"
export XDEBUG_CONFIG="idekey=PHPSTORM"
（私はphpstormを使用していますが、必要に応じて2番目のものを省略できます）
私は時々それに遭遇し、問題の本当の原因を見つけることができませんでした。
私は通常、
インスタンスを構築してクラスをロードするクライアントコードにブレークポイントをさらに配置します（XDebugは、クラスのロードの問題により、いくつかのブレークポイントを無視するようです）。いくつかのステップインを行うことにより、これらの場所がどこにあるかを学習し、理解することができます。
依存関係のソースパスを確認してください。 XDebugはこれらのファイルをフルパスで取得します。ブレークポイントパネルでIDEがどのようにそれらに対処するかを確認できます。
私の場合、問題は1つのプロジェクトでのみ発生しており（xdebug_breakを使用して中断できただけです）、他のプロジェクトでは問題なく機能していました。
ファイルの編集が修正されました：nbproject/private/private.properties：そして設定：
copy.src.files=false
プロジェクトを作成したときに、誤って「ソースのコピー」オプションを選択しました。次に、手動でプロジェクトを移動し、デバッガーが古いパス（copy.src.targetで設定）を探していたソースパス（「nbproject/project.properties」ファイル）を編集しました。
したがって、技術的には、このDEBUG問題を修正する別の方法は、nbprojectディレクトリを（それを削除してプロジェクトを再度作成することによって）再作成することです。デバッガーは、「コピー」オプションを有効にした状態で正常に動作するはずです（使用しないため）。
これがお役に立てば幸いです。
私にも同様の問題があり、問題を修正するための投稿を見つけました。私のHTMLフォーム（testform.html）がPHPスクリプト（runQuery.php）を呼び出していて、NetBeansは私のrunQuery.phpに設定されたブレークポイントでブレークできませんでした
このようなフォーラムで検索してphp.iniとNetbeansのすべての構成設定を確認した後、プロジェクトのインデックスファイルがPHPこれは非常に重要です。それ以外の場合は、ブレークポイントが機能しない理由を解明するために何時間も費やします。
Netbeansでは、ファイル/プロジェクトプロパティ/実行構成に移動し、インデックスファイルがPHPファイルであることを確認します。私の場合、インデックスファイルをtestform.htmlからtestform.phpに変更し、働いて、私はブレークポイントでブレークすることができました。
Web IDEでデバッグする際に、完全なセッションログを提供できますか？
ところで、Webを使用する場合IDE= IDEのキーはurlパラメータを介して自動的に割り当てられるため、通常はxdebug.idekey = webideを設定する必要はありません。
パス内の異常なシンボルに問題がある可能性もあります。たとえば、パスでコードを見つけました：
C:\[dev]\OpenServer\domains\...
そして、私は何もキャッチすることができませんでしたが、パスを変更した後、問題は消えました：
C:\dev\OpenServer\domains\...
したがって、括弧も重要です。
私の場合、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
私はこれらの構成が嫌いです。 lib Dephpuggerを知ったとき、私の人生は変わりました。
ターミナルで実行するデバッガーです（Pythonの場合はipdb、Rubyの場合はbyebugなど） https://github.com/tacnoman/dephpugger 非常に使いやすい。
パスに関しては、OSXファイルシステムは大文字と小文字を区別しませんが、xdebugはそうです
私の場合、/ [〜＃〜] p [〜＃〜]の代わりに/proj/test.phpを使用してスクリプトを実行していても、すべてが機能しているように見えましたroj/test.php。
Xdebug（または少なくとも現在のバージョン）がブレークポイントをチェックしている場合、チェックでは大文字と小文字が区別されます。ブレークポイントが/Proj/test.phpに設定されているが、スクリプトが/proj/test.phpを介して実行される場合、一致はありません。
PHPインクルードパスにも同様の問題がありました。パスに/ proj -directoryが含まれていましたが、これは誤りでした。コードの実行は機能しましたが、/ Projを使用してブレークポイントが設定されているため、ヒットしません。
これが問題かどうかを確認するには：
- ロギングを有効にする-dxdebug.remote_log =/tmp/remote.log
- ブレークポイントが設定されている場合は、ログで正確なパスを確認してください
- パスをPHPインタプリタが使用しているものと比較します。例：echo dirname（__ FILE__）;
件名の簡単な更新のために、私は新しい開発セットアップで同様の問題があり、それは明らかにバージョンの問題でした：少なくとも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にロールバックしましたが、今はすべて大丈夫です。
それが誰かを助けることを願っています;）