Ich habe Zugriff auf zwei Linux-Distributionen, beide angepasstes Debian.
Bei Verwendung eines identischen Testprogramms ist die generierte Kerndatei auf einem Computer etwa 35 MiB groß. Auf dem anderen Computer ist sie etwa 290 MiB groß. Das Programm erzeugt einige Threads, nimmt einige Zuweisungen vor und befindet sich dann in einer endlosen Busy-Loop.
Bei der Untersuchung des Kerns mit readelfsehe ich, dass der größere Abschnitt Abschnitte wie diesen enthält:
LOAD 0x000000000815e6b8 0x00007f8594021000 0x0000000000000000
0x0000000003fdf000 0x0000000003fdf000 R 0x1
Dies entspricht bei Betrachtung der Speicherzuordnungen folgendem:
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
Nach meinem Verständnis handelt es sich bei dieser Region um ungenutzten Speicher, der für Thread-Arenen reserviert ist.Die Region ist zur Laufzeit in beiden Distributionen vorhanden, wird aber nur in einer von ihnen in die Kerndatei geschrieben. Warum ist das so?
Es coredump_filterist bei beiden identisch (0x33), also liegt es daran nicht.
Bearbeiten:Ich bin weiter darauf zurückgekommen, dass es einen Unterschied in der Art und Weise gibt, wie die Ausführung gcoreeines Prozesses die virtuellen Speicherbereiche im Kernel ändert. Bei dem mit kleineren Kernen werden sie nicht als „beschrieben“ markiert, bei dem größeren jedoch schon. Genauer gesagt wird eine anon_vmaStruktur erstellt.