41

リモート デバッグを使用しているときに xdebug がブレークポイントで停止しないという問題があります (コマンド ライン経由でスクリプトを実行する場合はすべて問題ありません)。プログラムの最初の行で中断し、ブレークポイントをキャッチせずに終了します。

MacPorts for 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>

実行すると、デバッガーはアプリケーションの最初の行のコンテキストを取得し、detach および stop メッセージを送信します。

ただし、デバッガ起動時にこの行が出力されます。

<- 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>

「ライン条件呼び出しリターン例外」は何か意味がありますか?

4

24 に答える 24

34

私はこの問題を抱えていて、答えを見つけるのに何年もかかりました。

デバッグ構成のサーバー領域で、[構成] をクリックし、[パス マッピング] に移動し、そこにあるパスをクリックして [編集] をクリックし、[ファイル システムのパス] に変更して、正しいファイルに移動します。

終わり。

于 2011-01-13T03:04:46.993 に答える
22

私は同じ問題を抱えていましたが、最終的に、php.ini に次の 2 つの重要な設定がないことがわかりました。

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

その後、それは完全に機能しました。

于 2010-11-01T18:35:00.733 に答える
8

XDebugは、NetBeansを使用するUbuntu Lucidボックスで正常に動作し、php.ini（/etc/php5/apache2/php.ini）にzend_extension行があります。

xdebug2.0.4-2でnetbeans6.9とPHP5.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
于 2010-08-16T08:32:56.397 に答える
8

http://xdebug.org/docs/installから 、「php.iniに「extension=xdebug.so」を追加するためのプロンプトは無視する必要があります。これにより問題が発生します。」

だから、これは私のためにそれを修正しました：

設定ファイルで、xdebug拡張機能をロードします（私にとっては、CLIバージョンのphpの場合、それは/etc/php5/cli/conf.d/xdebug.iniでした）-指定しないでください

extension = xdebug.so

代わりに、

zend_extension = / path / to / xdebug / module / xdebug.so

（私にとって、これは/usr/lib/php5/(...)/xdebug.soのようなものでした）

locate xdebug.so場所を見つけるために使用します。

于 2010-03-11T11:33:08.663 に答える
7

同じ問題が発生しました。解決策は、ローカルコードをリモートコードと同じパスに配置することでした。

例

Webサーバーでは、コードは次のパスにあります。/var/www/dev01/app_name

ローカルでコードは私のホームディレクトリにありました：/home/me/projects/app_name

この構成により、IDE（EclipseとKomodo）はブレークポイントをまっすぐ通過しました。

ローカルパスをから/home/me/projects/app_nameに変更すると/var/www/dev01/app_name、問題が修正されました。sshfsを使用してリモートファイルシステムをローカルにマウントすると、さらに簡単になります。

于 2010-08-30T23:13:29.973 に答える
4

Komodoを使用して上記のsaflのコメントに似たようなことを経験しましたが、それが関連しているかどうかはわかりません:

Komodo で zend_extension を使用して xdebug をセットアップしましたが、完全に機能し、ブレークポイントと xdebug_break() を設定できますが、一部のファイルのみです。他は機能しませんでした。

解決策は、リモート パスとローカル パスのマッピングが発生する方法でした。Komodo はパス名の大文字と小文字を区別して比較を行っていることが判明したため、私のマッピングは完全には一致しませんでした。デバッガーがステップスルーして開いたファイルは正しいパスにありましたが、ide を介して開いたファイルには大文字のドライブレターが含まれていたため、明らかに Komodo が見落としていました。

于 2011-01-07T23:24:13.350 に答える
3

これらの解決策をすべて試してみましたが、役に立ちませんでした。XDebug は私のプロジェクトの 1 つでは機能しましたが、この新しいプロジェクトでは機能しなかったため、混乱しました。構成プロパティの比較につまずいた後、私は次のことに気付きました

プロジェクト プロパティ > ソース > Web ルート:

値はdefault value新しいプロジェクトでは a に設定されwebrootましたが、既存のプロジェクトでは に設定されました。そこで、プロジェクトの webroot を参照してその値を設定しました。私はそれをテストしましたが、バダビン、うまくいきました。

ここに画像の説明を入力

于 2012-05-07T18:54:15.753 に答える
2

経由で Xdebug をロードしていないことを完全に確信していますextension=xdebug.soか? php.iniこの行が表示された場合(出力などに表示された場合)、Xdebug はロードされますphpinfo()が、この方法でロードされた場合、ブレークポイントは機能しません。(デバッガー クライアントに接続し、ブレークポイントを受け入れます。トリガーされることはありません。)

行をコメントアウトして、まだロードされているかどうかを確認することをお勧めします。たとえば、zend_extensionXdebug を 経由でロードしていると思うかもしれませんが、背後に何かが追加されています。/etc/php5/conf.d/xdebug.ini/etc/php5/apache2/php.ini

詳細については、この質問と回答を参照してください。

于 2010-07-21T10:15:13.893 に答える
2

私はこれとまったく同じものに出くわし、しばらく頭をぶつけていました。ある時点で、PHP.ini に ZendDebugger.so も追加しましたが、それが Xdebug を壊していました。php.ini の ZendDebugger.so 行をコメントアウトすると、修正されました。

ZendDebugger を使用していない場合は、他の Zend 拡張機能を無効にして、競合の原因となっている別の拡張機能がないかどうかを確認してください。

于 2011-08-15T16:49:04.407 に答える
2

私はEclipseを使用していて、しばらく探しました。すべてphp.iniが正しかった。

最後に、 Eclipseではデバッガーがそのように設定されていることがわかりましたZEND-Debugger。私はそれを変更した後、XDEBUGそれはうまくいきました。

よろしくヨルグ

于 2013-02-15T07:56:03.457 に答える
0

私の場合、問題は 1 つのプロジェクトでのみ発生し (xdebug_break を使用してのみ中断できました)、他のプロジェクトでは問題なく動作していました。

ファイルを編集することで修正されました: nbproject/private/private.properties : そして設定:

copy.src.files=false

プロジェクトを作成したときに、誤って「ソースのコピー」オプションを選択しました。次に、プロジェクトを手動で移動し、そのソース パス (「nbproject/project.properties」ファイル) を編集しました。デバッガーはまだ古いパス (copy.src.target に設定) を探していました。

したがって、技術的には、この DEBUG の問題を解決する別の方法は、nbproject ディレクトリを再作成することです (ディレクトリを削除して、プロジェクトを再度作成します)。「コピー」オプションを有効にすると、デバッガーは正常に動作するはずです（私は使用したことがないため）。

これが役立つことを願っています。

于 2011-11-09T04:10:06.420 に答える
0

同様の問題があり、問題を解決するための投稿に出くわしました。私の html フォーム (testform.html) は php スクリプト (runQuery.php) を呼び出していましたが、Netbeans は私の runQuery.php に設定されたブレークポイントでブレークできませんでした。

このようなフォーラムを検索して、php.ini と Netbeans のすべての構成設定を確認した後、プロジェクトのインデックス ファイルが PHP ファイルである場合にのみ、netbeans がブレーク ポイントで壊れることを発見しました。これは非常に重要です。そうしないと、ブレークポイントが機能しない理由を突き止めるのに何時間も費やすことになります。

Netbeans で、ファイル/プロジェクト プロパティ/実行構成に移動し、インデックス ファイルが PHP ファイルであることを確認します。私の場合、インデックス ファイルを testform.html から testform.php に変更したところ、機能し、ブレーク ポイントでブレークできました。

于 2014-03-09T13:09:19.087 に答える
0

私は時々それにぶつかり、問題の本当の原因を見つけることができませんでした.

私は通常、

  1. インスタンスを構築してクラスをロードするクライアント コードにさらにブレークポイントを配置します (クラスのロードの問題により、XDebug がいくつかのブレークポイントを無視するように思われるため)。いくつかのステップインを行うことで、これらの場所がどこにあるかを学び、理解することができます。

  2. 依存関係のソース パスを確認します。XDebug はこれらのファイルをフル パスで取得します。IDE がブレークポイント パネルでこれらのファイルをどのように処理するかを確認できます。

于 2010-07-18T19:14:57.953 に答える
0

Web IDE でデバッグしようとしているときに、完全なセッション ログを提供していただけますか?

ところで、Web IDE を使用する場合、通常は xdebug.idekey=webide を設定する必要はありません。これは、ide キーが url パラメータによって自動的に割り当てられるためです。

于 2010-03-12T07:25:37.247 に答える
0

投稿にコメントできないため、この投稿にします。

私の問題の解決策は、ピッチアンドトーンが言ったのとよく似ていました。Eclipse は間違った二重パス マッピング アイテムを作成していました。それでも、相対パス (つまり、/project/folder) を使用できます。

于 2016-10-26T10:18:13.010 に答える
0

PHP CLI のデバッグの問題を修正するには、

環境変数を ~/.bashrc に追加します (後で再読み込みします):

export PHP_IDE_CONFIG="serverName=www.yourservernameurl.com"
export XDEBUG_CONFIG="idekey=PHPSTORM"

(私はphpstormを使用していますが、必要に応じて2番目のものを省略できます)

于 2020-01-15T15:00:52.443 に答える
0

PhpStorm でデバッグしようとしましたが、いくつかのブレークポイントで停止せず、Google で見つけたすべてのソリューションを試していたので、さらに無視し始めました。

問題は、実際にリクエストを処理するバックグラウンドで実行されている分離された複数の PHP プロセスがあったことです。デバッグ中のプロセスがリクエストを受信して​​いなかったため、PhpStorm はブレークポイントで停止しませんでした。これらのプロセスを殺すことで解決しました。

于 2016-09-06T14:07:17.040 に答える
0

パス内の異常なシンボルに問題がある可能性もあります。たとえば、コードをパスで配置していました。

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

そして、私は何も捕まえることができませんでしたが、パスの問題が消えた後:

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

したがって、括弧も重要です。

于 2016-05-20T15:38:02.000 に答える
-1

また、ファイルがローカルとリモートで同期されていることを確認してください。そうしないと、ブレークポイントが空の行などの無効な領域に到達し、機能しなくなります。

また、十分な権限があることを確認してください。NetBeans を介して同期しようとしましたが、許可が拒否されました

また、デバッガーを起動した後、ブラウザーの URL が正しく設定されていることを確認してください。私の nbproject フォルダーには古い URL が含まれていました。

于 2020-04-23T15:25:45.783 に答える