Linux のプロセスクラッシュの原因をコアダンプ技術を使用して追跡する簡単な分析

最近、プロジェクトで問題が発生しました。サーバー側のプログラムが突然クラッシュして終了しました。クラッシュの原因、つまりプロセスが終了したときに実行されていた関数とそのステータスを特定するために、コアダンプ技術を使用しました。

システムで coredump が有効になっている場合、より正確には、現在のシェル環境で coredump が有効になっている場合、現在のシェル環境のプログラムがクラッシュして終了すると、その時点でのプロセス スタックのメモリ状態がコア ファイルに書き込まれます。 gdb を使用して、このコア ファイル (gdb a.out core) に保存されているスタックのステータスを表示します。 (コアダンプとシェルの詳細については、私の別のブログ「dotnet-dump を使用して .net core 3.0 が CPU を 100% 占有する理由を調べる」を参照してください。gdb については、「gdb デバッグ コマンドの使用と概要」を参照してください)

コア ファイルのデフォルトの場所は実行可能ファイルの場所であり、デフォルトの名前は core です。場所と名前は設定できます。私の設定は次のとおりです。

mkdir /home/corefile 
echo "/home/corefile/core-%e-%p-%t" > /proc/sys/kernel/core_pattern

この方法では、生成されたコア ファイルは /home/corefile ディレクトリに配置され、コア ファイル名は core-%e-%p-%t の形式で表示されます。ここで、%e は実行可能ファイルの名前、%p はプロセス、%t はコア ファイルが生成された時刻 (Unix 時間であることに注意してください) を表します。

コアダンプを引き起こす可能性があるルーチンは次のとおりです。

交差した線は、コアダンプが発生する場所です。実行後、/home/corefile ディレクトリに次のファイルが生成されます。

[root@localhostwin7]# ls /home/corefile/ 

a.out は実行ファイル名、5082 は PID、1490760381 はファイルが生成された Unix 時間です。 a.out ファイルと core ファイルをディレクトリに配置し、次のコマンドを使用します。

gdb a.out core-a.out-5082-1490760381

gdb に入り、backtrace コマンドを使用して、プロセスが終了したときのスタックのメモリ ステータスを次のように表示します。

プロセスが終了すると、最後に実行される関数は square 関数であることがわかります。 ————————————————

要約する

上記は、Linux でプロセス クラッシュの原因をトレースするために coredump テクノロジを使用する方法について紹介したものです。お役に立てば幸いです。ご質問がある場合は、メッセージを残してください。すぐに返信いたします。