Tenho acesso a duas distribuições Linux, ambas Debian customizadas.
Usando um programa de teste idêntico, um arquivo principal gerado tem aproximadamente 35 MiB. Por outro lado, é de aproximadamente 290 MiB. O programa gera alguns threads, faz algumas alocações e, em seguida, faz loops ocupados para sempre.
Inspecionando o núcleo com readelf, vejo que o maior inclui seções como esta:
LOAD 0x000000000815e6b8 0x00007f8594021000 0x0000000000000000
0x0000000003fdf000 0x0000000003fdf000 R 0x1
O que, olhando os mapas de memória, 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
Entendo que esta região é uma memória não utilizada dedicada a arenas de threads.A região existe em ambas as distribuições em tempo de execução, mas só é gravada no arquivo principal de uma delas. Por que isso seria assim?
O coredump_filteré idêntico em ambos (0x33), então não é isso.
Editar:Além disso, descobri uma diferença na maneira como a execução gcorede um processo altera as regiões de memória virtual no kernel. Naquele com núcleos menores, ele não os marca como 'gravados', mas nos maiores, sim. Especificamente, cria uma anon_vmaestrutura.