私は 2 つの Linux ディストリビューションにアクセスでき、どちらもカスタマイズされた Debian です。
同一のテスト プログラムを使用した場合、生成されたコア ファイルは約 35 MiB です。一方、生成されたコア ファイルは約 290 MiB です。プログラムはいくつかのスレッドを生成し、割り当てを行ってから、永遠にビジー ループします。
でコアを検査するとreadelf、大きい方には次のようなセクションが含まれていることがわかります。
LOAD 0x000000000815e6b8 0x00007f8594021000 0x0000000000000000
0x0000000003fdf000 0x0000000003fdf000 R 0x1
メモリ マップを見ると、これは次のようになります。
7f8594021000-7f8598000000 ---p 00000000 00:00 0
Size: 65404 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: mr mw me nr
この領域はスレッド アリーナ専用の未使用のメモリであると理解しています。実行時には両方のディストリビューションに領域が存在しますが、そのうちの 1 つのコア ファイルにのみ書き込まれます。なぜそうなるのでしょうか。
はcoredump_filter両方とも同一 (0x33) なので、それではありません。
編集：さらに、プロセス上で実行することでカーネル内の仮想メモリ領域が変更される方法の違いまで突き止めましたgcore。コアが小さい方では、それらの領域が「書き込み済み」としてマークされませんが、コアが大きい方ではマークされます。具体的には、anon_vma構造体が作成されます。