4

マルチスレッドプログラムを実行していますが、1日か2日後にクラッシュします。さらに、コアダンプのgdbバックトレースはどこにもつながりません。クラッシュするポイントにはシンボルがありません。

これで、コアファイルを生成するマシンには、3ギガと5ギガのスワップスペースの物理メモリがあります。しかし、私たちが得るコアダンプは約25ギグです。コアダンプは実際にはメモリダンプではありませんか？コアダンプが大きいのはなぜですか？

そして、誰かがそのような状況でデバッグする方法について私にもっとリードを与えることができますか？

4

2 に答える 2

3

64 ビット OS を実行している場合は、利用可能な物理メモリ + スワップ スペースの量を何倍も超えるファイル ベースのマッピングを持つことができます。

カーネル バージョン 2.6.23 以降、Linux は、コア ダンプ ファイルに含まれるものを制御するメカニズムを提供します。これは、コア ダンプ フィルターと呼ばれます。/proc/<pid>/coredump_filterフィルタの値は、ファイルを介して操作されるビット フィールドです ( core(5)man ページを参照)。

  • ビット 0 ( 0x01) - 匿名のプライベート マッピング (動的に割り当てられたメモリなど)
  • ビット 1 ( 0x02) - 匿名の共有マッピング
  • ビット 2 ( 0x04) - ファイルに基づくプライベート マッピング
  • ビット 3 ( 0x08) - ファイルに基づく共有マッピング (共有ライブラリなど)
  • ビット 4 ( 0x10) - ELF ヘッダー
  • ビット 5 ( 0x20) - プライベート ヒュージ ページ
  • ビット 6 ( 0x40) - 共有されたヒュージ ページ

デフォルト値は、すべての匿名マッピングと ELF ヘッダー (ただし、カーネルが でコンパイルされている場合のみ) およびプライベート ヒュージ ページの0x33ダンプに対応するです。CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERSこのファイルから読み取ると、フィルターの 16 進値が返されます。新しい 16 進数値を書き込んcoredump_filterで、特定のプロセスのフィルターを変更します。たとえば、考えられるすべてのマッピングのダンプを有効にするには、次のようにします。

echo 0x7f > /proc/<pid>/coredump_filter

（<pid>プロセスのPIDはどこにありますか）

コア ダンプ フィルタの値は、 によって作成された子プロセスに継承されfork()ます。

一部の Linux ディストリビューションでは、OS の起動段階の早い段階でプロセスのフィルター値が変更される場合がありinitます。たとえば、ファイルに基づくマッピングのダンプを有効にするためです。これは、後で開始されるすべてのプロセスに影響します。

于 2012-07-31T08:13:53.683 に答える
2
于 2012-07-31T06:51:23.947 に答える