Tengo acceso a dos distribuciones de Linux, ambas Debian personalizadas.
Usando un programa de prueba idéntico, en uno un archivo principal generado es de ~35 MiB. Por otro lado, es ~290 MiB. El programa genera algunos subprocesos, realiza algunas asignaciones y luego realiza bucles ocupados para siempre.
Inspeccionando el núcleo con readelf, veo que el más grande incluye secciones como esta:
LOAD 0x000000000815e6b8 0x00007f8594021000 0x0000000000000000
0x0000000003fdf000 0x0000000003fdf000 R 0x1
Lo cual, mirando los mapas de memoria, corresponde a:
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
Entiendo que esta región es memoria no utilizada dedicada a campos de subprocesos.La región existe en ambas distribuciones en tiempo de ejecución, pero solo se escribe en el archivo principal de una de ellas. ¿Por qué esto sería así?
Es coredump_filteridéntico en ambos (0x33), así que no es eso.
Editar:Además, lo rastreé hasta encontrar una diferencia en la forma en que la ejecución gcorede un proceso cambia las regiones de memoria virtual en el kernel. En el que tiene núcleos más pequeños, no los marca como "escritos en", pero en el más grande, sí. Específicamente, crea una anon_vmaestructura.