Coredump size different than process virtual memory space

Question

I'm working on OS X 10.11, and generated dump file in the following manner :

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

and got dump file with the rolling attributes : 642M Jun 26 15:00 core.5228

Right before that, I checked the process total memory space using vmmap command to try and estimate the expected dump size.

However, the estimation (238.7Mb) was much smaller than the actual size (642Mb).

Can this gap be explained ?

                                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

score 1 · Answer 1 · edited Jun 20 '20 at 09:12

coredump can, and does, filter the process memory. See the core man page:

Controlling which mappings are written to the core dump

Since kernel 2.6.23, the Linux-specific /proc/PID/coredump_filter file can be used to control which memory segments are written to the core dump file in the event that a core dump is performed for the process with the corresponding process ID.

The value in the file is a bit mask of memory mapping types (see mmap(2)). If a bit is set in the mask, then memory mappings of the corresponding type are dumped; otherwise they are not dumped. The bits in this file have the following meanings:
      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.
By default, the following bits are set: 0, 1, 4 (if the CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS kernel configuration option is enabled), and 5. This default can be modified at boot time using the coredump_filter boot option.

I assume OS X behaves similarly.

Thanks for the thorough response, but does any of the optional data represented by bits 0-8 adding memory that is not accounted in process virtual mapped memory acquired by `VmSize` field in `/proc/self/status` ? — Zohar81, Jun 26 '16 at 13:33

Coredump size different than process virtual memory space

1 Answers1