2

I have a simple program:

#include <iostream>

int main() {
    std::cout << "Starting" << std::endl;
    while (1) {
    }

    return 0;
}

I compile and run it:

clang -o test test.cpp
bash$ ./test
Starting

In another terminal, I examine it and kill it:

bash$ top

Processes: 284 total, 3 running, 9 stuck, 272 sleeping, 1505 threads                       14:45:49
Load Avg: 1.86, 1.81, 2.06  CPU usage: 13.57% user, 0.96% sys, 85.45% idle
SharedLibs: 21M resident, 12M data, 0B linkedit.
MemRegions: 87372 total, 4974M resident, 86M private, 1203M shared.
PhysMem: 15G used (1887M wired), 1450M unused.
VM: 729G vsize, 1064M framework vsize, 3299196(0) swapins, 3711511(0) swapouts.
Networks: packets: 2686338/648M in, 2068186/355M out.
Disks: 1141818/44G read, 1926370/100G written.

PID    COMMAND      %CPU  TIME     #TH   #WQ  #PORT MEM    PURG   CMPRS  PGRP  PPID  STATE
30161  test         100.3 02:12.71 1/1   0    9     312K   0B     0B     29470 28181 running
66064  Terminal     2.7   01:29.69 9     3    257   53M    0B     4580K  66064 1     sleeping


bash$ ls -al /cores/
total 917024
drwxrwxr-t@  3 root    admin        102 May  1 14:54 .
drwxr-xr-x  33 root    wheel       1190 Apr 14 09:13 ..

bash$ killall -SIGSEGV test

bash$ ls -al /cores/
total 1818048
drwxrwxr-t@  4 root    admin        136 May  1 14:55 .
drwxr-xr-x  33 root    wheel       1190 Apr 14 09:13 ..
-r--------   1 stebro  admin  469516288 May  1 14:54 core.30161

vmmap says:

==== Summary for process 50745
ReadOnly portion of Libraries: Total=316K resident=280K(89%) swapped_out_or_unallocated=36K(11%)
Writable regions: Total=40.3M written=16K(0%) resident=12.1M(30%) swapped_out=14.4M(36%) unallocated=28.3M(70%)

REGION TYPE                      VIRTUAL
===========                      =======
Kernel Alloc Once                     4K
MALLOC                             9388K        see MALLOC ZONE table below
MALLOC (admin)                       24K
STACK GUARD                        56.0M
Stack                              8192K
VM_ALLOCATE                           4K
__DATA                              680K
__LINKEDIT                         70.9M
__TEXT                             5960K
shared memory                         4K
===========                      =======
TOTAL                             150.6M

                                 VIRTUAL ALLOCATION      BYTES
MALLOC ZONE                         SIZE      COUNT  ALLOCATED  % FULL
===========                      =======  =========  =========  ======
DefaultMallocZone_0x104a0e000      9216K        357        27K      0%

Why is my core file 469 MB?

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
Steve Broberg
  • 4,255
  • 3
  • 28
  • 40

1 Answers1

1

Your core dump includes the complete state of memory as well as symbol information for the frameworks and libraries that your application was running with at the time. That's a lot of data. For more information you might check out the core dumps section of technical note 2124

Scott Thompson
  • 22,629
  • 4
  • 32
  • 34
  • In the example above, I'm using no frameworks or libraries other than, presumably, the C runtime. It seems unlikely that this would be an almost 500MB footprint. I'm much more familiar with Solaris, where an application like this would produce a core file no larger than a megabyte, maybe, but you had to make sure you had the original binaries & libs to correctly interpret the corefile. From your link, it looks like there is no such option for OSX. – Steve Broberg May 01 '17 at 23:07
  • Since the core files in our case are being used as a diagnostic tool when automated tests fail, we should just switch using something like "sample 20821 2 -file /tmp/stack.txt" to gather what we need; a stack trace should be sufficient for our purposes. – Steve Broberg May 01 '17 at 23:13
  • It matters not if you are using the frameworks or not, they are mapped into the virtual memory space of your running application just in case you (or the standard C++ runtime) might need them. If you look to the technical note it mentions explicitly that Mac OS X core dumps are unusually large. – Scott Thompson May 01 '17 at 23:14
  • @SteveBroberg: For insight, try applying `vmmap -w -interleaved ` on your process. – Ken Thomases May 02 '17 at 01:10
  • @KenThomases: See my edit to the question above; vmmap gives some insight, but still leaves about 300 MB unaccounted for. – Steve Broberg May 02 '17 at 13:36