1

質問が述べているように、すべてのエラー関数とシグナルハンドラーでソフトウェアベースのバックトレース（libcバックトレースhttp://www.gnu.org/software/libc/manual/html_node/Backtraces.htmlを使用するなど）を常に収集することは有用ですか？ ？

メモリ、同時実行性のバグなど、さまざまなバグのデバッグにはあまり役立ちませんか？エラーパスでのみトリガーされるだけでなく、通常のパフォーマンスを損なうことはないと思います。

4

1 に答える 1

2

質問が述べているように、ソフトウェアベースのバックトレースを常に収集することは有用ですか

はい、一般的に、次の場合にクラッシュスタックトレースを作成すると非常に便利です。

  • コードは独自の環境で実行され、スタックトレースが秘密を明らかにすることを心配する必要はありません。
  • クラッシュハンドラがコアダンプをさらに破損しない場合、ハングしない場合など。

libcバックトレースを使用するような

glibcは特定の条件下でbacktrace呼び出し、クラッシュハンドラーでは安全ではありません。callocこれは、ハングと上記のさらなる破損の両方を引き起こす可能性があります。スタックトレースを非同期信号に対して安全な方法で確実に出力するクラッシュハンドラを作成することは、非常に簡単ではありません。

では、なぜ「標準」アプリケーションのエラー関数がバックトレースを呼び出さないのでしょうか。

考えてみてくださいcat /no/such/file。現在、以下を生成します。

cat: /no/such/file: No such file or directory

あなたが本当に知る必要があるのはこれだけです。この印刷物を他のものにすることは無意味です。そのようなファイルがたくさんあり、catがそれぞれの完全なスタックトレースを出力した場合、エラー出力のページが多くなり、実際の問題を見つけるのが難しくなります。

致命的なシグナルハンドラー（例SIGSEGV）の場合、答えは、ほとんどの「標準」アプリケーションは実際にはそのようなシグナルを処理せず、コアダンプを生成するデフォルトのアクションを使用するだけです。

backtraceただし、シグナルをキャッチした場合、、、backtrace_symbolsまたはシグナルハンドラーからの呼び出しbacktrace_symbols_fdも同様に安全ではなく、デッドロックが発生する可能性があります。これは、単にコアをダンプするよりもはるかに悪いことです。1000個のコマンドを含む長時間実行スクリプトがある場合にどうなるかを考えてみてください。それを開始すると、1週間後、2番目のコマンドがクラッシュし、クラッシュスタックトレースを印刷しようとしてデッドロックしたため、進行しなかったことがわかりました。

于 2013-01-08T04:17:41.667 に答える