0

非常にネストされたシナリオ（たとえば、非常に小さな解析エラーを持つ別のオブジェクトインスタンスを参照する別のオブジェクトインスタンスを参照するオブジェクトインスタンス）に存在する場合、PHPでの単純な解析エラーに気付いたのは私だけではないと確信しています。 、それらはすべて自動ロードされます）解析エラーを報告して通常のように実行を停止する代わりに、PHPを永久にハングさせる可能性があります—これは何度も何度も見られ、非常に異なるコードベースで、常に適切なerror_reporting設定が設定されています。

それを回避する方法はありますか？つまり、どういうわけか、解析エラーレポートを表示するように強制できますか？

記録として、これらのハングは、PHPが解析エラーを正しく処理しなかった結果として発生したと100％確信しています。これは、この動作を何度もデバッグしたためです。私が尋ねる理由は、これらのハングが発生すると、基本的に暗闇に置かれ、PHPがおかしな動作をしているのか、コードのどこかに誤動作しているループがあるのか​​さえわからないためです。これにはデバッグに時間がかかります。ご存知のように、PHPが解析エラーを報告した場合は保存されます。

4

2 に答える 2

2

コメントで部分的に言及されているように、error_reporting(E_ALL)すべてのエラーを表示するのに役立ちます。また、の値を使用ini_setして作成する必要がある場合もあります。display_errorson

個人的には、あなたの質問はあまり明確ではないと思います。フォーマットを改善して、より理解しやすくする必要があります。

更新：コードを実行しているサーバー/コンピューターは非常に遅いようです。「ぶらぶら」は実際には発生しないはずです。それとも、それをさらに詳しく説明していただけますか？

また、無限ループまたはほぼ無限ループに陥る可能性があります。すべてのコードを投稿しない限り、これが私たちがあなたを助けることができる限界であるため、あなたのコードを注意深くチェックしてください。

更新2：オブジェクトを呼び出そうとしたときに、オブジェクトの名前を誤って入力した可能性があります。それ以外の場合は、オブジェクトを正しく宣言していない可能性があります。

ほとんどの場合、どちらか一方です。

于 2012-08-26T03:00:38.847 に答える
0

犯人はxdebug.collect_paramsであることが判明しました。これは、ドキュメントが非常に正確に無効にしておくことを示唆しています。特定のエラーは、コールスタックトレースの引数に非常に大量のデータを生成するだけで、collect_paramsを4に設定してxdebugを使い果たし、xdebugを作成し、拡張機能としてPHPをハングさせました。 xdebugからスタックトレースを取得しますが、どうやらxdebugはこのデータを収集しているようです。

これはデバッグが困難でした。理由は次のとおりです。a）複製が簡単ではなかったb）xdebugを使用したプロファイリングが役に立たなかったc）xdebug + dbgpを使用したコードのステップ実行も役に立たなかったd）トレースがほとんど残っていない（しゃれが意図されていない）非常にまれにエラーをphperror_logファイルに記録し、e）カスタム例外ハンドラーを使用するよりも、例外の処理プロセスにxdebugを関与させなかったため、xdebugの疑いがあることは明らかではありませんでした。

ですから、死の構文解析エラーのようなものはありません、そして私はそれが私のせいではないと決して仮定しないことを学びました:)この答えが少なくとも将来他の人を助けることを願っています。

于 2012-08-30T23:29:12.107 に答える