Core Dumps
Purpose
Guide agents through enabling, collecting, and analysing core dumps for post-mortem crash investigation without rerunning the buggy program.
Triggers
- "My program crashed in production — how do I analyse the core?"
- "How do I enable core dumps on Linux?"
- "I have a core file but no symbols / source"
- "How do I use debuginfod to get symbols for a core?"
- "coredumpctl show me the crash"
Workflow
1. Enable core dumps (Linux)
2. systemd/coredumpctl (modern Linux)
If systemd manages core dumps (common on Ubuntu 20+, Fedora, Arch):
Core storage location: /var/lib/systemd/coredump/.
3. Enable core dumps (macOS)
4. Analyse a core with GDB
5. Analyse a core with LLDB
6. Missing symbols: debuginfod
debuginfod serves debug symbols from a central server, mapping build IDs to DWARF data.
7. Missing symbols: manual approach
8. Strip binaries and keep symbols
Best practice: build with symbols, strip for distribution, keep an unstripped copy.
9. Quick triage from core without full debug session
For a full cheatsheet covering core pattern tokens, coredumpctl, GDB/LLDB commands, debuginfod servers, and strip/symbol workflows, see references/cheatsheet.md [blocked].
Related skills
- Use
skills/debuggers/gdbfor full GDB session details - Use
skills/debuggers/lldbfor LLDB-based analysis - Use
skills/runtimes/sanitizersto catch the bug before it reaches production - Use
skills/binaries/elf-inspectionforreadelf, build IDs, and binary inspection


