저는 두 개의 Linux 배포판(둘 다 Debian 사용자 정의)에 액세스할 수 있습니다.
동일한 테스트 프로그램을 사용하면 생성된 코어 파일 중 하나는 ~35MiB입니다. 반면에 ~290MiB입니다. 프로그램은 일부 스레드를 생성하고 일부 할당을 한 다음 영원히 바쁜 루프를 반복합니다.
으로 코어를 검사해 보면 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
나는 이 영역이 스레드 아레나 전용으로 사용되지 않는 메모리라는 것을 알고 있습니다.영역은 런타임 시 두 배포판 모두에 존재하지만 둘 중 하나의 코어 파일에만 기록됩니다. 왜 그럴까요?
둘 다(0x33)에서 동일 하므로 coredump_filter그렇지 않습니다.
편집하다:gcore프로세스에서 실행하면 커널의 가상 메모리 영역이 변경되는 방식의 차이점까지 추가로 추적했습니다 . 코어가 더 작은 코어에서는 '작성됨'으로 표시되지 않지만 더 큰 코어에서는 표시됩니다. 구체적으로 말하면 구조를 생성합니다 anon_vma.