为什么 OSX 核心文件这么大？答案

【问题标题】：Why are OSX core files so large?为什么 OSX 核心文件这么大？
【发布时间】：2023-03-10 09:33:01
【问题描述】：

我有一个简单的程序：

#include <iostream>

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

    return 0;
}

我编译并运行它：

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

在另一个终端，我检查它并杀死它：

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 说：

==== 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%

为什么我的核心文件是 469 MB？

【问题讨论】：

标签： macos memory clang

【解决方案1】：

您的核心转储包括内存的完整状态以及您的应用程序当时运行的框架和库的符号信息。这是很多数据。有关更多信息，您可以查看technical note 2124 的核心转储部分

【讨论】：

在上面的例子中，我没有使用任何框架或库，大概是 C 运行时。这似乎不太可能占用近 500MB 的空间。我对 Solaris 更熟悉，像这样的应用程序可能会生成不超过 1 兆字节的核心文件，但您必须确保拥有原始二进制文件和库才能正确解释核心文件。从您的链接来看，OSX 似乎没有这样的选项。
由于我们案例中的核心文件在自动化测试失败时被用作诊断工具，我们应该使用类似“sample 20821 2 -file /tmp/stack.txt”之类的东西来收集什么我们需要;对于我们的目的，堆栈跟踪应该足够了。
是否使用框架并不重要，它们被映射到正在运行的应用程序的虚拟内存空间中，以防万一您（或标准 C++ 运行时）可能需要它们。如果您查看技术说明，它明确提到 Mac OS X 核心转储异常大。
@SteveBroberg：为了深入了解，请尝试在您的流程中应用vmmap -w -interleaved <pid>。
@KenThomases：请参阅我对上述问题的编辑； vmmap 提供了一些见解，但仍有大约 300 MB 的空间下落不明。