問題タブ [debug-backtrace]

機能が強すぎて、安定性や性能が心配です。

どう思いますか？

アップデート

私がやっていることはこれです：

基本的にはそうするだけですがinclude ( $included_file );、その中で$included_fileそれ自体が入っているのと同じディレクトリにあるものを見つけることができない3.phpので、手動でcwdを設定して動作します.しかし、見つからない理由を見つけたらいいと思います. . なぜdebug_backtrace必要なのかというと、相対パスが機能しないため、3.php別のものに含まれているためです.funcdebug_backtrace

上記のコードはメソッドのコンテキスト内にあるため、再現するのは簡単ではありません..他の誰もこのような問題に遭遇していない場合は、ここでやめたいと思います.とにかく、コストはわずか3余分です.行、大したことではありません。

debug_backtrace() 以外で呼び出し元の関数を取得する方法はありますか?

friendやinternalなどのスコープをシミュレートするための貪欲でない方法を探しています。

クラスAとクラスBがあるとしましょう。

今までdebug_backtrace()は欲張りすぎる(私見ですが)を使っていました。

私は次のようなことを考えました：

特定の 1 つのクラスに制限したい場合は問題ないかもしれませんが、300 のクラスがあり、そのうちの 25 に制限したいとしましょう。

1 つの方法は、インターフェースを使用して集約することです。

public function __construct(CallerInterface $callerObj)

しかし、それでも醜いコードです。

さらに、そのトリックは静的クラスでは使用できません。

もっと良いアイデアはありますか？

symfony アプリをデバッグしようとしています。

この関数を呼び出す debug_backtrace() を以下に追加しました。呼び出された関数のリストを出力しますが、save() 関数 (debug_backtrace() 呼び出しの直前) はそのリストではありません..なぜですか? より多くのものを表示する他のデバッグ方法、この場合は save() の呼び出しですか?

よろしく

ハビ

print_r(debug_backtrace(), true) を使用して、デバッグ バックトレースの文字列表現を取得しています。print_r は再帰を処理するため、これは正常に機能します。

debug_backtrace() の戻り値の配列を文字列に変換する前に再帰的に反復しようとすると、再帰が発生し、終了しませんでした。

バックトレース配列から特定の重要なキーと値のペアを削除する簡単な方法はありますか? おそらく、print_r を使用して配列を文字列に変換し、再帰位置を文字列RECURSIONに変更して配列に戻す何らかの方法で、反復処理を行うことができます。

可能であれば、文字列表現に対して正規表現を実行したくありません。

PHP 5.3.4 を使用していますが、debug_print_backtrace を使用しようとしても、何も得られません。以下に示すように、vardump を使用すると、空の配列が得られます。

index.php:

返す

誰が何が悪いのか教えてもらえますか? 実行中に呼び出されたすべてのものが表示されることを期待しています。その代わり、何も見えません。

見つけたメッセージを調べましたが、役立つと思われる回答が見つかりませんでした。debug_backtrace() を呼び出して要素を循環し、ログに適切な形式で出力するルーチンがあります。ほとんどの場合、これで問題なく動作します。

一部の呼び出しでは、システムがハングするだけです。以下を仮定します。

場合によっては、PHP が停止することがあります。現在のアイテムを処理したログを確認できますが、foreach 行でクラッシュします (少なくとも、次の $myStackLevel.

ここの 1 つのメッセージで、再帰呼び出しとシリアル化の使用について何かを見ましたが、シリアル化を使用できません (私は PDO を使用しており、「PDO インスタンスをシリアル化または非シリアル化することはできません」というメッセージが表示されました)。

面白いのは、クラッシュした場合でも、PHP エラー システムがスタックの完全なダンプを提供することです.... (シリアル化を使用しようとしたときにこれを見つけました)。

どんな助けでも大歓迎です....

ありがとう、

ジャストミートゥー

この質問への答えをいじくり回しているときに、その中から呼び出されたときに、にdebug_backtrace()登録されている関数を超えてトレースしないことがわかりました。register_shutdown_function()

これは、PHPドキュメントのこのコメントで言及されており、次のように述べています。register_shutdown_function()

致命的なエラーが発生した場所を追跡するために、シャットダウン関数内から debug_backtrace または debug_print_backtrace を呼び出すという考えが浮かぶかもしれません。残念ながら、これらの関数はシャットダウン関数内では機能しません。

もう少し詳しく説明すると、この回答の状態に関するコメント:

うまくいきません。シャットダウン機能は、スタックが巻き戻された後に発生します。ダンプするスタック情報がありません。

これを回避して、プロセスが完全に終了するまで PHP にスタック トレースを強制的に保持させる方法はありますか、それとも PHP の内部構造により、スタック トレースをそのまま受け入れる必要がありますか?

デバイスが切断または接続されたときにランダムにクラッシュするプログラムがあります。btコマンドを実行するgdbと、次のようになります。

XCode は NSApplicationMain で中断しますが、コードのどこにもありません。すべての例外で中断するように指示しました。これは、これがBluetoothスタック自体の内部で起こっていると私に思わせています。これは正しいですか？これを防ぐ方法はありますか、または少なくともこれを試してキャッチして、クリーンアップしてクラッシュを防ぐ方法はありますか?

子プロセスをフォークするアプリケーションがあります。

子プロセスはいくつかの作業を行い、途中でセグメンテーション違反を引き起こします。これをデバッグするためにGDBを使用しました。

また、子内の関数にブレークポイントを設定しました。しかし、GDB はブレークポイントで一時停止しません。

また、親プロセスが seg-fault を処理するため、ctrl-c で終了する必要がありました。次にbacktrace、スタックを印刷するために使用すると、得られるのは

スタックなし

ブレークポイントが設定されていないのはなぜですか? また、スタックを取得できなかったのはなぜですか?

debug_backtraceそのため、PHP リフレクションを使用して、アスペクト指向設計をアーキテクチャに実装しようとしています。設計は機能しますが、それがパフォーマンスにどれほど悪影響を与えるかを確認することにしたので、次のプロファイリング テストを作成しました。興味深いことに、 メソッドAdvisableとNonAdvisableメソッドが何もしない場合、推奨される方法を使用した場合と推奨されない方法を使用した場合の約 5 倍の影響がありますが、各メソッドの複雑さを増すと (ここでは反復回数を増やして30 以上)、推奨される方法のパフォーマンスが向上し始め、複雑さが増すにつれてパフォーマンスが向上し続けます。

基本クラス:

実装されたクラス:

そして、メソッドをプロファイリングします:

複雑度 100 (A::executions = 100) でこのテストを実行すると、次の結果が得られます。

何か案は？