崇高なテキスト内でphp用のxdebugを設定していますが、xdebugは接続できないことに関連するエラーをログに記録し続けます。
Log opened at 2016-08-18 21:06:01
I: Connecting to configured address/port: localhost:9988.
E: Could not connect to client. :-(
Log closed at 2016-08-18 21:06:01
ブラウザでhttp://localhost:9988
に移動して直接デバッグすると役立つことを期待していましたが、単にgoogle chromeエラーページ: "localhost refused toconnect"]が表示されます。おそらくエラーはもう一方の端では、そのデータを崇高なテキストクライアントにプッシュすることはできません、私にはわかりません。崇高なテキストxdebugは、tests/etcを実行すると、「Reloading/var/log/xdebug/xdebug.log」というメッセージを表示します。そのため、実行されているphpコードを認識しているようですが、それ以上は実行されません。
したがって、xdebug自体をデバッグする必要があるとは思っていませんでしたが、xdebugからコードエディターへの接続をデバッグするにはどうすればよいですか?これがnginxの場合、仮想ホストのデバッグを開始しますが、xdebugであるため、接続するアプリがないためにどこからデバッグを開始すればよいかわかりません。
私はubuntulinux14.04を使用しています。
該当する場合は、xdebug.iniのconfを次に示します。
[xdebug]
xdebug.default_enable=1
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remote_Host="localhost"
xdebug.remote_handler="dbgp"
xdebug.remote_port=9988
xdebug.remote_mode = req
xdebug.overload_var_dump=0
xdebug.idekey = sublime.xdebug
xdebug.remote_log="/var/log/xdebug/xdebug.log"
;https://github.com/martomo/SublimeTextXdebug
インストールされているXdebug:
apt-cache policy php-xdebug
php-xdebug:
Installed: 2.4.0-5+donate.sury.org~trusty+1
Candidate: 2.4.0-5+donate.sury.org~trusty+1
Version table:
*** 2.4.0-5+donate.sury.org~trusty+1 0
500 http://ppa.launchpad.net/ondrej/php/ubuntu/ trusty/main AMD64 Packages
100 /var/lib/dpkg/status
アクティブなモジュール:
php -m | grep -i xdebug
xdebug
Xdebug
phpinfo xdebug設定:
PHPのデバッグには、連携する2つのコンポーネントが必要です。サーバーとして機能するPHP拡張機能と、この拡張機能と通信してその機能を駆動する方法を知っているソフトウェア(クライアント)です。
ただし、クライアントがサーバーに接続する通常のクライアントサーバープロトコルにもかかわらず、PHPデバッガーは逆に機能します。サーバーは、クライアントに接続するサーバーです(起動する必要があります)。ポート9000
でリッスンします)。
xdebug
は最もよく知られているPHPデバッグ用の拡張機能です。クライアントとして機能するプログラムやプログラム拡張機能/プラグインはたくさんあります。Xdebugパッケージを使用していませんでした。 Sublimeの場合(そもそもSublimeを使用していませんでした)、原則は同じです。
クライアントソフトウェア(この場合はXdebugパッケージでSublime)は、localhost
のポート9000
でリッスンを開始し、サーバーが接続を開始するのを待ちます。おそらく、ポートを常にリッスンするわけではなく、開発者がそう言った場合に限ります。
PHPスクリプトを開始してデバッグします。xdebug
はサーバーへのすべてのリクエストを開始するわけではなく、リクエストにマーカーが見つかった場合にのみ開始します。スクリプトの実行に使用されるSAPIによっては、マーカーは、環境変数(CLIスクリプトの場合)またはcookie、またはGET
またはPOST
引数(Webページの場合)のいずれかです。詳細については、ドキュメントの "Starting The Debugger" セクションを参照してください。
PHPインタープリターがPHPスクリプトの実行を開始すると、xdebug
が上記のマーカーを見つけた場合、xdebug
クライアントに接続しようとします。それ以外の場合は、そのままです。邪魔にならないようにして、スクリプトをフルスピードで実行できるようにします。
デバッグマーカーが環境に存在する場合、xdebug
拡張機能(サーバー)はxdebug
クライアントへの接続を試みます(デフォルトではlocalhost
のポート9000
ですが、これらの設定は必要に応じて変更できます)。接続できない場合(クライアントがリッスンしていないため)、障害をログに記録し、邪魔にならないようにして、スクリプトをフルスピードで実行します。
クライアントに正常に接続した後、xdebug
PHP拡張機能は、PHPスクリプトの最初のステートメントを実行する前に停止するか、実行がブレークポイント。この動作とブレークポイントのリストは、接続が確立されたときの最初の通信中にクライアントからサーバーに送信されます。その後、拡張機能はクライアントからのコマンドを待機します。クライアントは、実行中のスクリプトの現在の状態を開発者に表示します。 (実行する次のステートメント、現在のスコープ内の変数の値など)、コマンドを待ちます(次のステートメントの実行、続行、ブレークポイントの追加/削除、変数の監視など)。
あなたの質問からはあまり明確ではありませんが、xdebug
クライアント(xdebug
)を実行しているのと同じコンピューターで(PHPインタープリターとlocalhost
拡張子を使用して)Webサーバーを実行していると仮定します。そうでない場合でも、絶望しないでください。解決策はコマンドラインから離れたところにあります(回答の最後を読んでください)。
質問に投稿した情報から、xdebug
がインストールされ、有効になっていて、正しく機能していることがわかります。 telnet localhost 9988
の出力は、ポート9988
で誰もリッスンしていないことを示しています。 xdebug
クライアントはそこでリッスンする必要があります。
私はSublimeText(およびそのパッケージ)を扱ったことがありません。 この記事 インストールして機能させる方法を説明します。ただし、ポート9988
でリッスンするように構成する方法については説明していません。
PHP xdebug
拡張子をデフォルトのポート(9000
)に接続するように設定することから始めます。
xdebug.remote_port=9000
次に、すべてが機能する場合は、Sublime Textxdebug
パッケージを別のポートでリッスンするように構成する方法を見つけようとします。別のポートでリッスンするために本当に必要ですか?
xdebug
クライアントが異なるコンピューター上にある場合はどうなりますか?リモートマシンで実行されるPHPスクリプト)をデバッグする必要がある場合、xdebug
クライアントはローカルマシン(ポート9000
)でリッスンし、xdebug
拡張機能はリモートマシンのポート9000
に接続しようとします。イントラネットとVPNで可能な解決策は、ローカルマシンのポート9000
に接続するようにxdebug
を構成することですが、これらの条件とは別に、通常、ファイアウォールやその他のセキュリティソフトウェアの変更も必要です。
リモートマシンにssh
アクセスできる場合この状況でPHPスクリプトをデバッグする最も簡単な方法は、ポート9000
からssh
トンネルを作成することです。ローカルマシンのポート9000
へのリモートマシンの接続。
ssh
を使用してリモートマシンに接続する(ファイルを配置する)と仮定すると、リモートマシンに接続してssh
セッションを開始するために使用するコマンドラインに-R 9000:localhost:9000
を追加するだけです。
この接続が開いている限り、リモートマシン(9000
)のポート9000
(上記のコマンドラインの最初の-R
)での接続要求は、トンネルを介してのポート9000
(コマンドラインの2番目の9000
)に転送されます。ローカルマシン(localhost
)。このようにして、リモートxdebug
PHP拡張機能はリモートxdebug
クライアントに接続できます(リッスンしていると想定)。
さて、さまざまな設定を徹底的にテストした後、私の後に来る人々のために問題をデバッグするための私の提案があります:
1つのxdebugクライアントのみでのテストに依存しないでください! 2つのエディター/ IDEをインストールするのは簡単なので、代替エディターを実行して、xdebugに問題があるのか、特定のクライアントに問題があるのかを確認できるようにします。
Xdebug + xdebugクライアントの組み合わせの構成を保持する3の場所が存在する可能性があります。クライアント(またはエディタープラグイン)構成、20-xdebug-conf.iniファイル(または同等のphp.ini)、およびプロジェクト固有の構成。 port、path_mappingなどに関して3つの場所すべてが同期していることを確認してください。