У меня есть доступ к двум дистрибутивам Linux, оба из которых являются модифицированными версиями Debian.
Используя идентичную тестовую программу, на одном сгенерированный файл ядра составляет ~35 МБ. На другом — ~290 МБ. Программа порождает несколько потоков, делает несколько выделений, затем бесконечно зацикливается.
Проверяя ядро с помощью 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
Я понимаю, что эта область представляет собой неиспользуемую память, выделенную для потоковой арены.Регион существует в обоих дистрибутивах во время выполнения, но записывается в файл ядра только в одном из них. Почему так?
Значение coredump_filter0x33 на обоих устройствах одинаковое, так что дело не в этом.
Редактировать:Я далее отследил это до разницы в том, как запуск gcoreпроцесса изменяет области виртуальной памяти в ядре. На том, у которого меньше ядер, он не помечает их как «записанные», но на большем — делает. В частности, он создает структуру anon_vma.