8

デーモンとして実行されるトラフィックの多いネットワーク C サーバー アプリケーションを開発しています。状況によっては、アプリがクラッシュします (常にコアなし)。実行中のデーモンを gdb でデバッグして、SIGSEGV を生成する場所を見つけるにはどうすればよいですか?

注釈:

  1. attach コマンドを使用して、gdb を使用して実行中のプロセスにアタッチする方法を知っています

  2. プロセスにアタッチした後、停止します。実行してから「続行」すると、プログラムがクラッシュしない限り、gdb はブロックされたままになります。CTRL-C を押すと、プロセスが終了し、単純に gdb を切り離すことができません。

問題は、gdb がスタックせずにプロセスを続行する方法はありますが、プロセスがクラッシュしない場合にデタッチできる方法はありますか?

4

3 に答える 3

8

非同期モードを試して、「続行 &」:

以下をnon-stop.gdbに保存します

set target-async on
set pagination off
set non-stop on

次に実行します。

$ gdb -x non-top.gdb
(gdb) !pgrep YOUR-DAEMON
1234
(gdb) attach 1234
(gdb) continue -a &
(gdb)
于 2013-04-23T14:20:27.243 に答える
3

このページのアタッチ/デタッチは、detachコマンドが 内で機能することを示していgdbます。

アプリケーションでセグメンテーション違反をキャッチする場合は、デバッガーからアプリケーションを実行する必要があります。次に、シグナルがキャッチされたら、whereまたはbt を使用して、アプリケーションのスタック トレースを表示できます。もちろん、障害が発生した後にアプリケーションを続行することはできません。どのように回復すればよいでしょうか? すぐに障害をトリガーすることが予想される場合は、実行中のプロセスにアタッチして、デバッガーで障害を再び待機することができます。

障害が発生した後にスタック トレースが必要な場合は、アタッチするプロセスがないため、実際にはコア ファイルが必要です。デーモンがシステムの一部として起動されている場合、設定でコア ダンプを取得するのが難しい場合があります。さらに、他のアプリケーションがコア ダンプをいたるところに残したくない場合もあります。そのため、システム デーモンを停止し、ユーザー空間で再起動することをお勧めします。その後、コア ダンプを許可できます。システムの一部として起動することが本当に重要な場合は、デーモンの起動が単一のサブシェルに限定されているかどうかを確認し、そのサブシェルで使用ulimit -cして、コア ダンプの適切な最大サイズを設定します。 .

于 2013-04-23T12:18:27.787 に答える