gdb - Solaris コア ダンプ分析

Question

pstack を使用して、Solaris のコア ダンプ ファイルを分析しています

他に、solaris からのコア ダンプを分析するにはどうすればよいですか?

これを行うには、どのコマンドを使用できますか?

ダンプから他にどのような情報が得られますか?

Answer 1

Solaris モジュラー デバッガ、mdb、または dbx を使用できます。mdb には、SUNWmdb (または 64 ビット バージョンの場合は SUNWmdb x) パッケージが付属しています。

コア ファイルは、クラッシュした時点で実行中のプロセスのイメージです。

アプリケーションがデバッグ フラグを使用してコンパイルされたかどうかに応じて、スタックのイメージを表示できるため、どの関数がコアを引き起こしたかを知り、その関数に渡されたパラメータの値を取得できます。変数の、割り当てられたメモリゾーン...

最近の solaris バージョンでは、coreadm コマンドを使用して、コア ファイルに含まれるものを構成できます。たとえば、プロセスがアタッチされたメモリ セグメントをマップすることができます。

MDB のドキュメントとdbx のドキュメントを参照してください。GDB の基本を理解すれば、GDB クイック リファレンスカードも役に立ちます。

Answer 2

コア ダンプが作成またはビルドしたプログラムからのものである場合は、実行中のアプリケーションのデバッグに通常使用するデバッガを使用します。それらはすべて、コア ファイルをロードできる必要があります。デバッガにこだわりがなく、Solaris を使用している場合は、dbx をお勧めします。パッチを適用した最新の FCS バージョンの Sun Studio を入手するか、最新の Express バージョンの Sun Studio を入手すると役立ちます。また、コア ファイルが作成されたシステムと同じシステムのデバッガーにコア ファイルをロードできると、非常に役立ちます。ライブラリ内のコードがコア ファイルの作成時と異なる場合、スタック トレースはライブラリを通過するときに役に立ちません。デバッガーは、libthread とランタイム リンカーのデータ構造を理解するために OS ヘルパー ライブラリも使用するため、コア ファイルを別のマシンにロードする必要がある場合は、OS にインストールされているヘルパー ライブラリが OS のシステム データ構造と一致していることを確認する必要があります。数年前に書かれたホワイト ペーパーで、これらのシステム ライブラリについて知りたくなかったすべてのことを知ることができます。

http://developers.sun.com/solaris/articles/DebugLibraries/DebugLibraries_content.html

Answer 3

この質問に対する答えは、簡単なレシピから始める必要があると思います。

dbx の場合、レシピは次のとおりです。

% dbx a.out core
(dbx) where
(dbx) threads
(dbx) thread t@3
(dbx) where

Answer 4

pflagsコマンドは、各スレッドがコアダンプされたときの状態を判別するのにも役立ちます。このようにして、問題を特定できることがよくあります。

Answer 5

dbx デバッガーを使用してプロセス イメージに接続します。

dbx [executable_file_name] [coredump_file_name]

コアがダンプされた (つまり、再構築されていない) ため、実行可能ファイルに変更がないことが重要です。

スタック トレースを表示して、dbx コマンド「where」でプログラムがクラッシュした場所を確認できます。

コマンド「up」と「down」でスタックを上下に移動したり、「frame [number]」で正確なスタック フレームにジャンプしたりできます。数値は「where」の出力に表示されます。

「print [expr]」コマンドを使用して、変数または式の値を出力できます。

楽しむ。

Answer 6

GDB を使用できます。

ダンプの前に試行された呼び出しを与えることができます。

http://sourceware.org/gdb/

http://en.wikipedia.org/wiki/GDB

ソースがあることは素晴らしいことです。エラーを再現できれば、これを使用してデバッグすることができます。

過去に私のためにうまくいきました。