一般的な PHP デバッグの問題のトラブルシューティング

PhpStorm デバッグログの収集

このセクションで問題が解決されない場合は、サポートエンジニアにお問い合わせください。 デプロイログの提供を求められた場合は、 指示に従ってログを収集してください。

Xdebug ログの収集

Xdebug を使用する場合、 アクションをログに記録(英語)させることができます。

1. 設定 ダイアログ（Ctrl+Alt+S ）で PHP に移動します。

2. PHP 実行可能ファイル リストから、関連する PHP インタープリターを選択し、その横にある をクリックします。 開いた CLI インタープリター ダイアログで、 構成ファイル: <php.ini へのパス> ファイルの横にある エディターで開く リンクをクリックします。 すべてのダイアログを閉じて、 php.ini ファイルが開かれているタブに切り替えます。

3. php.ini で、次の行を追加して Xdebug ロギングを有効にします。

   xdebug.log="path_to_log/xdebug.log"

   xdebug.remote_log="path_to_log/xdebug.log"

   ログファイルには、PhpStorm と Xdebug の間の生の通信や、警告・エラーが含まれています：

   Log opened at 2018-01-08 08:14:28 I: Connecting to configured address/port: 127.0.0.1:9000. I: Connected to client. :-) -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///C:/Projects/Samples/DebuggingTutorial/debugging.php" language="PHP" protocol_version="1.0" appid="3040" idekey="11774"><engine version="2.2.5"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2018 by Derick Rethans]]></copyright></init> <- step_into -i 5 -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="step_into" transaction_id="5" status="break" reason="ok">< xdebug:message filename="file:///C:/Projects/Samples/DebuggingTutorial/debugging.php" lineno="2"></xdebug:message></response>

Xdebug または Zend デバッガーがインストールされ、設定されていることを確認する

PhpStorm で PHP コードをデバッグするには、 Xdebug または Zend Debugger のいずれかのデバッグエンジンがインストールされ、正しく構成されていることを確認してください。

これらのツールは、互いにブロックし合うため、同時に使用することはできません。 この問題を回避するには、 Xdebug を構成する および Zend デバッガーの構成 の説明に従って、 php.ini ファイルの対応するセクションを更新する必要があります。

デバッグエンジンの設定を検証するには、 デバッグエンジンの構成を検証する

デバッガーの動作を妨げる起動時の警告とエラー

PHP を実行しているときに、起動時の警告またはエラーが表示される場合があります。 この場合、デバッガーが機能しない可能性があります。 PhpStorm は、使用されているデバッガーも認識できません。

起動時の警告またはエラーが表示されないことを確認するには、次のコマンドを実行します。

これにより、次のようなメッセージが返されます。

最初の行にエラーまたは警告がある場合は、続行する前に修正することをお勧めします。

デバッガーが接続できない

デバッガーが接続できない場合、または接続を拒否する場合は、以下を確認してください。

• Xdebug または Zend Debugger が、PhpStorm が実行されているホストとポートに接続するように構成されていることを確認してください。

  • Xdebug 構成で、 xdebug.remote_host および xdebug.remote_port (Xdebug 3 の場合は xdebug.client_host および xdebug.client_port) が正しいことを確認してください。 詳細については、 Xdebug のドキュメント(英語)を参照してください。

  • Zend Debugger を使用する場合は、生成した PhpStorm ブックマークレットまたは ブラウザーデバッグ拡張機能が正しい IP アドレスとポートを使用するように設定されていることを確認してください。

  • リモート PHP インタープリターを使用する場合は、 SSH トンネル経由のリモートデバッグ に記載されている手順を確認してください。

• 設定 ダイアログ（Ctrl+Alt+S ）で、 PHP | デバッグ に移動し、PhpStorm と Xdebug/Zend Debugger が同じポート番号で構成されていることを確認してください。

• PhpStorm で、以下のいずれかの方法で受信デバッグ接続のリッスンを有効化します：

  • ツールバー / ステータスバーの をクリックします。

  • メインメニューで 実行 | PHP デバッグ接続のリッスンを開始 を選択します。

  これにより、Web サーバーでデバッグセッションが開始されると PhpStorm が反応し、 デバッグツールウィンドウ が自動的に開きます。 デバッグセッションを開始する前に、 ブレークポイントが設定されているか、 設定 ダイアログ Ctrl+Alt+S の デバッグ ページで PHP スクリプトの最初の行で中断する。 オプションが有効になっていることを確認してください。

• ファイアウォール、ルーター、ISP が接続をブロックしていないことを確認します。 これはリモートサーバー（PhpStorm を実行しているローカルマシンの IP アドレス）で telnet host 9000 (for Xdebug) または telnet host 10137 （Zend Debugger 用）を実行し、接続が確立されていることを確認することで確認できます。 http://www.canyouseeme.org などのサービスを使用して、開いている受信ポートを確認できます。

• xdebug.remote_host （Xdebug 2 の場合）、 xdebug.client_host （Xdebug 3 の場合）、または zend_debugger .allow_hosts （Zend デバッガーの場合）が正しく構成されていることを確認してください。 値は、ホスト名（例： localhost ）または PhpStorm が動作しているマシンの IP アドレスで、サーバーから ping が通る必要があります。 Xdebug を使用する場合、トラブルシューティングには xdebug.remote_connect_back(英語) （Xdebug 2 の場合）または xdebug.discover_client_host(英語) （Xdebug 3 の場合）を使用できます。

PhpStorm はデバッグセッションから切断されました

Xdebug のステップデバッガーが正しく有効になっても、PhpStorm がリクエストを続行せず、デバッグセッションから切断する場合があります。 その場合、PhpStorm の デバッグログファイルおよび Xdebug のログファイルに、切断理由を示すエラーメッセージが記録されます：

• File is under skipped path

  Xdebug がデバッグしようとするファイルは、PhpStorm の設定の PHP | デバッグ | スキップするパス にあります。 このファイルをデバッグするには、 スキップするパス リストから削除してください。

• File is a phpinfo helper script

  分離は、PhpStorm のコード編集ヘルパーである phpinfo.php ファイルへの Xdebug の介入によって発生します。

• File is under skipped path or a phpinfo helper script

  上記を参照。

• Debugging session ended

  デバッグセッションが終了したため、PhpStorm と Web サーバー間の接続ステータスが disconnected に変更されます。

• Cannot bind file to the web server project

  PhpStorm は Web サーバーに接続しましたが、このデバッグ接続をリッスンしている PhpStorm プロジェクトを Web サーバー上のプロジェクトにマップできませんでした。

• External connection stopped working

  PhpStorm と Web サーバー間の接続がありません。

• No external connection found

  PhpStorm は登録された外部 Xdebug 接続を見つけることができませんでした。

• Project lost

  PhpStorm プロジェクトはデバッグセッションの途中で終了しました。

• Error occurred

  詳細についてはエラーの説明を参照してください。

デバッグサーバーが構成されていない

Debug server を設定せずにゼロ構成デバッグセッションを開始した場合、接続確立時に PhpStorm が 受信接続ダイアログ を表示し、 server access configuration （deployment configuration ）からマッピングのインポートを提案します。 デプロイからマッピングをインポートする を選択すると、PhpStorm は最適なデプロイ構成を検出し、 デプロイ リストで事前選択し、 プレビューエリア には選択した構成のマッピングに従い、現在実行されているスクリプトに対応するプロジェクトファイルまでの絶対パスが表示されます。

PhpStorm が関連する構成を検出しない場合：

1. リストから最適な構成を選択するか、 をクリックして開き、 デプロイ ダイアログで新しい構成を作成すると、新しい構成がリストに追加されます。

2. デプロイルート フィールドに、サーバーのルートフォルダーへの絶対パスを入力します。

また、 手動でローカルファイルまたはプロジェクトを選択する オプションを選択すると、PhpStorm のプロジェクトツリービューが表示され、プロジェクトファイルを選択して現在実行中のスクリプトをそこにマッピングできます。 プロジェクト全体を選択してマップすることもできます。

インポートまたは手動で指定した構成設定を使用してデバッグを続行するには、 受諾 をクリックします。

リモートファイルパスはプロジェクト内のファイルパスにマッピングされていません。

デバッガーが接続できる場合もありますが、リモートとプロジェクトファイル間のマッピングが定義されていないことを示すエラーメッセージが表示されます。 これは、PhpStorm がデバッグ中のファイルに対応するローカルファイルを判別できないことを意味します。

この問題を解決するには、 クリックしてパスマッピングを設定する をクリックして、必要なパスマッピングを提供します。

パスマッピングは、サーバーで処理されるファイルのパスが PhpStorm プロジェクト内のファイルのパスと異なる場合に使用されます。 これは、次の場合に発生します。

• サーバーはリモートで、プロジェクトファイルはオリジナルのローカルコピーです。

• サーバーで処理されるファイルと IDE で開かれたファイルは同じですが、シンボリックリンクが使用されます。 デバッガーはデバッグセッション中にシンボリックリンクを解決するため、IDE の実際の溶質にサーバー上のファイルへの物理パスを伝える必要があります。

パスマッピングを構成するには、 設定 ダイアログ (Ctrl+Alt+S) で PHP | サーバー に移動します。

サーバーが処理しているファイルがプロジェクトにあり、シンボリックリンクを使用していない場合は、 パスマッピングを使用する チェックボックスをオフにします。 この場合、IDE はデバッガーから受け取ったパスに従ってファイルを開きます。

親ディレクトリに指定されたパスマッピングは、そのすべてのサブディレクトリに自動的に適用されます。 必要に応じて、サブディレクトリまたはファイルのパスマッピングを指定できます。

詳細については Web サーバーに接続する を参照してください。

ブレークポイントがヒットしていない

ブレークポイントにヒットしていないが、デバッガーが接続しているように見える場合は、次のことを確認してください。

• ブレークポイントが無効になっていないことを確認します。 実行 | ブレークポイントの表示 メニューコマンド Ctrl+Shift+F8 を使用して、ブレークポイントが有効になっていることを確認します。 ブレークポイントを有効にするには、ブレークポイントの横にあるチェックボックスを選択します。

• パスマッピングが正しいことを確認してください。

• macOS で Finder を使ってファイルやフォルダーをリネームし、文字の大文字・小文字を変更した場合、PhpStorm がファイルを見つけられなくなることがあります。 名前の変更が必要な場合は、IDE で行うか、ターミナルと mv コマンドを使用してください。 Finder を使用してプロジェクトファイルまたはフォルダーの名前を変更すると、奇妙な動作が発生する可能性があります。 詳細については、 こちら(英語)を参照してください。

• ごくまれに、PHP がバイトコードを生成する仕組みなど技術的な制限により、ブレークポイントがヒットしない場合があります。 詳細については、 こちらをご覧ください。

Xdebug を使うときは、 xdebug_break() 関数を使って PHP 内からブレークポイントを強制することができます。 実行中に Xdebug がこの関数を検出すると、もともとそこにブレークポイントが定義されていなくても、IDE の次のステートメントで一時停止します。

Xdebug はブレークポイントを無視し、ブレークポイントが定義されていない行で停止する

これは、Xdebug の内部 ブレークポイント解決メカニズムが原因で発生する可能性があります。 このメカニズムで、デバッガーは、PHP が現在の行の内部実行可能バイトコードを生成できるかどうかを評価します。 ブレークポイントが参照する行にそのようなコードがない場合、対応するブレークポイントにヒットできません。 Xdebug は、後続の最大 5 行までスキャンし、実行可能コードが配置されている行で停止し、ブレークポイントの定義をこの行に更新します。

デバッグセッション中に PhpStorm がブレークポイントを解決および移動してほしくない場合は、 PHP | デバッグ ページの 設定 ダイアログ（Ctrl+Alt+S ）でこの機能を無効化できます。

Xdebug エリアでは:

• 現在の行で使用できない場合はブレークポイントを解決する (Xdebug 2.8+) チェックボックスの選択を解除して、ブレークポイント解決機能全体を無効にします。 解決が無効になっている場合、実行可能コードのないコード行に設定されたブレークポイントは常に無視されることに注意してください。

• ソースと異なる場合は、ブレークポイントを解決された位置に移動する チェックボックスの選択を解除して、ブレークポイントの解決後に Xdebug が実際に停止する行へのブレークポイント位置の自動調整のみを無効にします。 ブレークポイント解決機能は引き続き有効になることに注意してください。

設定 領域で、 ブレークポイントが別の行に解決されたかどうかを通知する (Xdebug 2.8+) チェックボックスの選択を解除して、ブレークポイントが解決されるたびに PhpStorm の通知をオフにします。

スクリプトは中断されていません

ゼロコンフィギュレーションデバッグセッションの確立は、ブレークポイントにヒットせずに失敗する場合があるため、スクリプトは中断されません。 これは、 パスマッピングが構成されていない、または誤って構成されている場合、またはブレークポイントを設定していない場合に発生することがあります。 後者の場合、次のいずれかを実行できます。

• 目的の実行可能コード行のガターをクリックしてブレークポイントを設定します。 詳細は ブレークポイント を参照してください。

• 設定 ダイアログ (Ctrl+Alt+S) で PHP | デバッグ に移動し、 外部接続 領域で PHP スクリプトの最初の行で中断する。 チェックボックスを選択します。

• メインメニューから 実行 | PHP スクリプトの最初の行で中断する オプションを有効にします。

スクリプトが中断されていない場合、PhpStorm に通知を表示させるには、 設定 ダイアログの PHP | デバッグ ページの 詳細設定 領域の デバッグセッションが一時停止せずに完了した場合に通知する チェックボックスを選択してください。

nginx を使用しているときにデバッガーが動作しない

nginx(英語) Web サーバーを使用する場合、 $_SERVER["SERVER_NAME"] が PHP によって提供されていないと、デバッグが失敗することがあります。 これを解決するには、nginx 構成に fastcgi パラメーターを追加します。

または

詳細については、 nginx のドキュメント(英語)と このコミュニティの投稿(英語)を参照してください。

Xdebug は PhpStorm に接続できません

Xdebug ログに以下のメッセージが表示された場合:

または

これは、Xdebug がホストへの接続を試み、接続を確立できないことを意味します。 この問題を修正するには、 xdebug.remote_connect_back=0 （Xdebug 3 の場合は xdebug.discover_client_host=false ）を設定し、 xdebug.remote_host （Xdebug 3 の場合は xdebug.client_host ）が正しく設定されていることを確認します。

フレームワーク CLI コマンドをデバッグしようとすると、PHP エラーが発生する

Symfony コンソールや Laravel Artisan などの PHP フレームワークコマンドラインツールの CLI コマンドをデバッグしようとすると、PHP エラー Fatal error: Class '...\Command' not found" などでデバッグが失敗します。

このようなエラーの一般的な原因は、コマンドを使用してファイルまたはクラスを直接デバッグしようとすることです。 代わりに、コマンドラインツールへのパスと実際に実行するコマンドを指定する PHP スクリプト を使用する必要があります。 この場合、フレームワークコマンドのブートストラップロジックが適用され、デバッグが正常に進行します。

詳細については、次のフレームワーク固有のガイドを参照してください。

• Symfony CLI コマンドのデバッグ

• Artisan CLI コマンドのデバッグ

• Wordpress WP-CLI コマンドのデバッグ

• Drush CLI コマンドのデバッグ

Zend デバッガーは特権の削除を実行しません

Linux で Zend デバッガーを使用すると、次のエラーが表示されることがあります。

このエラーは、デバッガーが Web サーバープロセスを実行しているユーザーの UID を特定できない場合に発生します。 そのユーザーの UID を見つけて、それを php.ini に追加します。

設定を更新したら、Web サーバーを再起動してください。

ionCube をインストールしてデバッグする

一部の PHP 環境では、 ionCube(英語) を使用してエンコードされた PHP コードをロードして実行します。 ionCube ローダー拡張機能は、実行される PHP コードをデコードし、PHP インタープリターがそれを実行できることを確認することによってこれを行います。

正式には、Xdebug も Zend デバッガーも ionCube を有効にしても動作しませんが、いくつかの回避策があります。 これらは JetBrains、ionCube、Xdebug、Zend デバッガーではサポートされていません。

• ionCube ローダーモジュールが最初にロードされていることを確認する

  php.ini で、ionCube ローダーが任意のデバッガー拡張機能よりも前に読み込まれていることを確認してください。例えば：

  zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/ioncube_loader_lin_5.4.so zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so

• ionCube オンデマンドローディングを使用する

  php.ini で ionCube 拡張を無効にして、ionCube のオンデマンドロード機能を利用することができます。 最初のエンコードされた PHP スクリプトがロードされると、PHP インタープリターは設定された extension_dir をチェックして ionCube 拡張子を見つけ、エンコードされた PHP スクリプトを実行します。

  この方法は正式にサポートされていないことに注意してください。 デバッグ目的でのみ使用し、本番サーバーでは使用しないでください。