MacOS下如何编程生成更小core dump？setrlimit相关疑问

Absolutely, you can shrink macOS core dumps programmatically with setrlimit() and RLIMIT_CORE—let’s walk through how this works, what data gets dropped when you cap the size, and some extra tips to keep your core files useful but small.

Basic Usage of setrlimit(RLIMIT_CORE) #

First, the straightforward part: you can set a soft and hard limit on the maximum size of core dumps your process can generate. The soft limit is what the system enforces by default, and the hard limit is the upper bound (non-root processes can’t exceed it).

Here’s a quick C example you can drop into your macOS app (works in Objective-C too, and you can call the POSIX APIs from Swift with a bit of bridging):

#include <sys/resource.h>
#include <stdio.h>

int main() {
    struct rlimit core_limit;
    
    // Set soft limit to 256MB, hard limit to 512MB
    core_limit.rlim_cur = 256 * 1024 * 1024;
    core_limit.rlim_max = 512 * 1024 * 1024;
    
    if (setrlimit(RLIMIT_CORE, &core_limit) != 0) {
        perror("Failed to set core limit");
        return 1;
    }
    
    // Rest of your app logic here...
    return 0;
}

If the core dump would exceed rlim_cur, macOS truncates it to that size instead of failing to generate it entirely.

What Gets Discarded When You Limit Core Size #

macOS core dumps default to including your entire process virtual address space—this includes heap allocations, stack memory, mapped shared libraries, anonymous memory blocks, and even cached file data. When you set a size limit, the system truncates the core file from the highest memory address downwards, so the last (highest-address) memory regions get dropped first.

Here’s what you’ll typically lose when truncating:

• Large anonymous memory blocks: These are often uninitialized or unused heap regions, or big buffers that don’t contain critical state for debugging.
• Shared library segments: Debuggers like lldb can load the original shared libraries from disk, so their copies in the core dump are usually redundant. These are often in higher memory regions, so they get trimmed first.
• Memory-mapped file data: If your app maps large files into memory (like caches), those can be reloaded from the original file during debugging—no need to store them in the core.
• Non-active stack memory: The current call stack (the part that tells you where the crash happened) lives in lower stack addresses, so it’s usually preserved. Only the unused, higher parts of the stack get cut.

⚠️ Important: If you set the limit too small (e.g., a few MB), you might truncate critical parts of the core file, making it unreadable by debuggers. Test with a reasonable size that balances disk usage and debuggability.

Extra Tips to Reduce Core Dump Size #

Beyond setrlimit(), there are more targeted ways to shrink core dumps:

• Mark memory regions as non-dumpable: When using mmap() to allocate memory, add the MAP_NOCORE flag. This tells macOS to skip writing that region to the core dump entirely—perfect for large buffers that don’t hold crash-critical data.
• Tweak system-wide core dump filters: Use the sysctl utility (or sysctlbyname() in code) to adjust kern.coredump_filter. macOS uses this to exclude certain memory types (e.g., memory marked with VM_MAP_FLAGS_NOCORE). You can set it to filter out more non-essential regions.
• Post-process core files: After generating a core, use tools like coreutils to strip unnecessary sections, or convert it to a smaller format if you only need specific debugging info.

Verifying Your Setup #

After setting the limit, trigger a crash (e.g., send a SIGSEGV to your process) and check the core file size. Then load it in lldb:

lldb --core core.12345

If you can still inspect the call stack, register values, and critical heap data, your limit is set correctly.

内容的提问来源于stack exchange，提问作者RuLoViC