3

コア ファイルを関連する実行可能ファイルおよび共有ライブラリとバンドルするにはどうすればよいですか?

プログラムがクラッシュすると、gdb でデバッグするために使用できるコア ファイルが生成されます。しかし、誰かが私の後ろに来て、余分なデバッグをオンにしてプログラムを「助けて」再コンパイルしたり、パッケージをアップグレードしたり、何らかの方法でシステムをいじったりすると、そのコアファイルは役に立たなくなります。

そこで私が望むのは、コア ファイルとそれが参照する他のすべてのバイナリを 1 つの大きなファイルにバンドルする方法です。

そしてもちろん、このファイルを gdb で開く方法も必要です。ファイルを元の場所に「抽出」して、アップグレードまたは変更されたバイナリを上書きする必要はありません。バイナリを一時ディレクトリに抽出し、そこを探すようにgdbに指示するシェルスクリプトを想像しています。

4

3 に答える 3

0

SIGSEGV をトラップし、サブプロセスを記述して、関連するプロセス ファイルを (lsof を使用して) 一時ディレクトリにコピーすることができます。

于 2012-07-05T21:14:10.453 に答える
0

まず、コアに関連付けられているバイナリを見つけます。いくつかのオプションがあります:

  1. 原因となったバイナリに基づいてコアに名前を付けるようにシステムを構成し、スクリプトがそれらを取得できる標準の場所にバイナリをインストールします。コアに名前を付ける手順はこちらにあります。また、core(5) も参照してください。

  2. システムを構成できない場合、私が思いついた最善の方法は、コアで文字列を実行し、有効なパスである各文字列に対して「ファイル」を実行し、「ELF」と「実行可能ファイル」を grep することです。これにより、間違った答えが得られる可能性があります。特に、バイナリが別のユーティリティ (make など) によって呼び出された場合、コアに表示される可能性があるため、わかっている場合は /bin および /usr/bin 内のパスを除外するなどの追加のフィルターを追加できます。バイナリは常に /opt にあり、最新の mtime を持つバイナリを選択します (新しいソフトウェアは、システムに同梱されているソフトウェアではなく、コアリングされている可能性が高く、自分のものである可能性が高くなります)。

  3. 補足的なトリックは、文字列出力で「_=/your/binary/here」を探すことです。「_」は、一部のシェル/WM/アプリによって、呼び出しているバイナリに設定される特別な環境変数です。ただし、誤解を招く可能性もあります (たとえば、make がバイナリを呼び出すと /usr/bin/make になります)。

次に、バイナリの依存関係を収集します。

  1. LD_PRELOAD および LD_LIBRARY_PATH の値について、コアから出力された文字列を再度 grep します。これらは、バイナリが実際にリンクしたライブラリに影響を与える可能性があります。
  2. これらの変数を同じ値に設定してバイナリで「ldd」を実行し、「=>」で分割して、各ライブラリのファイル名を見つけます。

次に、すべてをディレクトリにコピーし、tar を実行します。多くの場合、ログ ファイルをディレクトリにコピーすることも役立ちます。

于 2012-10-01T02:26:06.227 に答える