內核轉儲大小比進程的虛擬內存空間不同

Question

我工作的OS X 10.11，並生成轉儲文件以下列方式：

1. ulimit -c unlimited 
2. kill -10 5228 (process pid) 

，並得到轉儲文件與滾動屬性：642M Jun 26 15:00 core.5228

在此之前，我使用vmmap命令檢查了進程總內存空間，嘗試並估計預期的轉儲大小。

然而，估計（238.7Mb）遠小於實際大小（642Mb）。

可以解釋這個差距嗎？

       VIRTUAL REGION 
REGION TYPE      SIZE COUNT (non-coalesced) 
===========      ======= ======= 
Activity Tracing     2048K  2 
Kernel Alloc Once     4K  2 
MALLOC guard page     16K  4 
MALLOC metadata     180K  6 
MALLOC_SMALL      56.0M  4   see MALLOC ZONE table below 
MALLOC_SMALL (empty)    8192K  2   see MALLOC ZONE table below 
MALLOC_TINY      8192K  3   see MALLOC ZONE table below 
STACK GUARD      56.0M  2 
Stack        8192K  2 
__DATA       1512K  44 
__LINKEDIT      90.9M  4 
__TEXT       8336K  44 
shared memory      12K  4 
===========      ======= ======= 
TOTAL       238.7M  110 

           VIRTUAL ALLOCATION  BYTES   REGION 
MALLOC ZONE       SIZE  COUNT ALLOCATED % FULL COUNT 
===========      ======= ========= ========= ====== ====== 
DefaultMallocZone_0x100e42000  72.0M  7096  427K  0%  6 

Answer 1

coredump可以，也可以過濾進程內存。看到core man page：

其映射被寫入到核心控制轉儲

由於內核2.6.23，Linux的特異性/ proc /進程/ coredump_filter文件可以被用來控制內存段如果爲具有相應進程ID的進程執行核心轉儲，則將其寫入核心轉儲文件。

該文件中的值是內存映射類型的位掩碼（請參見mmap（2））。如果在掩碼中設置了一位，則轉儲相應類型的存儲器映射;否則他們不會被傾銷。該文件中的位具有下列含義：

 bit 0 Dump anonymous private mappings. 
     bit 1 Dump anonymous shared mappings. 
     bit 2 Dump file-backed private mappings. 
     bit 3 Dump file-backed shared mappings. 
     bit 4 (since Linux 2.6.24) 
      Dump ELF headers. 
     bit 5 (since Linux 2.6.28) 
      Dump private huge pages. 
     bit 6 (since Linux 2.6.28) 
      Dump shared huge pages. 
     bit 7 (since Linux 4.4) 
      Dump private DAX pages. 
     bit 8 (since Linux 4.4) 
      Dump shared DAX pages. 

默認情況下，下面的位被設置：0，1，4（如果CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS內核配置選項已啓用）和5這種默認可以修改在啓動時使用coredump_filter啓動選項。

我假設OS X的行爲相似。