/core-dumps
Core dump analysis skill for production crash triage. Use when loading core files in GDB or LLDB, enabling core dump generation on Linux/macOS, mapping symbols with debuginfo or debuginfod, or extracting backtraces from crashes without re-running the program. Activates on
$ npx -y skills add mohitmishra786/low-level-dev-skills --skill core-dumps --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/core-dumps
Context preview
The summary Claude sees to decide when to auto-load this skill.
Core dump analysis skill for production crash triage. Use when loading core files in GDB or LLDB, enabling core dump generation on Linux/macOS, mapping symbols with debuginfo or debuginfod, or extracting backtraces from crashes without re-running the program. Activates on
SKILL.md
core-dumps.SKILL.mdname: core-dumps
description: Core dump analysis skill for production crash triage. Use when loading core files in GDB or LLDB, enabling core dump generation on Linux/macOS, mapping symbols with debuginfo or debuginfod, or extracting backtraces from crashes without re-running the program. Activates on queries about core files, ulimit, coredumpctl, debuginfod, crash triage, or analyzing segfaults from production binaries.
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)
# Per-session (lost on logout)
ulimit -c unlimited
# Persistent (add to /etc/security/limits.conf)
* soft core unlimited
* hard core unlimited
# Check current limit
ulimit -c
# Set core pattern (where and how cores are named)
# Default: 'core' in CWD — often not useful
sudo sysctl -w kernel.core_pattern=/tmp/core-%e-%p-%t
# %e = executable, %p = PID, %t = timestamp
# Persistent (add to /etc/sysctl.d/99-core.conf)
kernel.core_pattern=/tmp/core-%e-%p-%t
kernel.core_uses_pid=1
2. systemd/coredumpctl (modern Linux)
If systemd manages core dumps (common on Ubuntu 20+, Fedora, Arch):
# List recent crashes
coredumpctl list
# Show details of the latest crash
coredumpctl info
# Load latest crash in GDB
coredumpctl gdb
# Load specific PID crash
coredumpctl gdb 12345
# Export core file
coredumpctl dump -o myapp.core PID
Core storage location: `/var/lib/systemd/coredump/`.
3. Enable core dumps (macOS)
# macOS uses /cores by default (must be root-writable)
ulimit -c unlimited
# Check
ls /cores/
# launchd-launched services: set in plist
# <key>HardResourceLimits</key>
# <dict><key>Core</key><integer>9223372036854775807</integer></dict>
4. Analyse a core with GDB
# Load binary and core
gdb ./prog core.12345
# If the binary was stripped, provide the unstripped copy
gdb ./prog-with-symbols core.12345
# Essential first commands
(gdb) bt # call stack
(gdb) bt full # stack + locals
(gdb) info registers # CPU state at crash
(gdb) frame 2 # jump to interesting frame
(gdb) info locals # local variables in frame
(gdb) print ptr # inspect a pointer
# All threads (multi-threaded crash)
(gdb) thread apply all bt full
5. Analyse a core with LLDB
lldb ./prog -c core.12345
# Or
lldb
(lldb) target create ./prog --core core.12345
# Commands
(lldb) bt
(lldb) thread backtrace all
(lldb) frame select 2
(lldb) frame variable
6. Missing symbols: debuginfod
`debuginfod` serves debug symbols from a central server, mapping build IDs to DWARF data.
# Install client (Debian/Ubuntu)
sudo apt install debuginfod
# Enable (add to ~/.bashrc or /etc/environment)
export DEBUGINFOD_URLS="https://debuginfod.ubuntu.com https://debuginfod.elfutils.org"
# GDB auto-fetches symbols when DEBUGINFOD_URLS is set
gdb ./prog core
# Manually query
debuginfod-find debuginfo <build-id>
debuginfod-find source <build-id> /path/to/file.c
7. Missing symbols: manual approach
# Check if binary has a build ID
readelf -n ./prog | grep Build
# Find the correct debug package
# Debian: apt install prog-dbg or prog-dbgsym
# RPM: dnf install prog-debuginfo
# Point GDB to debug symbols directory
(gdb) set debug-file-directory /usr/lib/debug
# Or use eu-readelf to dump build ID, then find .debug file
eu-readelf -n ./prog
find /usr/lib/debug -name "*.debug" | xargs eu-readelf -n 2>/dev/null | grep <build-id>
8. Strip binaries and keep symbols
Best practice: build with symbols, strip for distribution, keep an unstripped copy.
# Build
gcc -g -O2 -o prog main.c
# Separate debug info
objcopy --only-keep-debug prog prog.debug
objcopy --strip-debug prog prog.stripped
# Add a debuglink so GDB finds the debug file automatically
objcopy --add-gnu-debuglink=prog.debug prog.stripped
# Deploy prog.stripped; keep prog.debug in a symbols store indexed by build-id
9. Quick triage from core without full debug session
# Print backtrace non-interactively
gdb -batch -ex 'bt full' -ex 'thread apply all bt full' ./prog core 2>&1 | tee crash.txt
# Print registers
gdb -batch -ex 'info registers' ./prog core
# Check signal that caused crash
gdb -batch -ex 'info signal' ./prog core
For a full cheatsheet covering core pattern tokens, coredumpctl, GDB/LLDB commands, debuginfod servers, and strip/symbol workflows, see [references/cheatsheet.md](references/cheatsheet.md).
Related skills
- Use `skills/debuggers/gdb` for full GDB session details
- Use `skills/debuggers/lldb` for LLDB-based analysis
- Use `skills/runtimes/sanitizers` to catch the bug before it reaches production
- Use `skills/binaries/elf-inspection` for `readelf`, build IDs, and binary inspection
Read more
name: core-dumps description: Core dump analysis skill for production crash triage. Use when loading core files in GDB or LLDB, enabling core dump generation on Linux/macOS, mapping symbols with debuginfo or debuginfod, or extracting backtraces from crashes without re-running the program. Activates on queries about core files, ulimit, coredumpctl, debuginfod, crash triage, or analyzing segfaults from production binaries.
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)
# Per-session (lost on logout) ulimit -c unlimited # Persistent (add to /etc/security/limits.conf) * soft core unlimited * hard core unlimited # Check current limit ulimit -c # Set core pattern (where and how cores are named) # Default: 'core' in CWD — often not useful sudo sysctl -w kernel.core_pattern=/tmp/core-%e-%p-%t # %e = executable, %p = PID, %t = timestamp # Persistent (add to /etc/sysctl.d/99-core.conf) kernel.core_pattern=/tmp/core-%e-%p-%t kernel.core_uses_pid=1
2. systemd/coredumpctl (modern Linux)
If systemd manages core dumps (common on Ubuntu 20+, Fedora, Arch):
# List recent crashes coredumpctl list # Show details of the latest crash coredumpctl info # Load latest crash in GDB coredumpctl gdb # Load specific PID crash coredumpctl gdb 12345 # Export core file coredumpctl dump -o myapp.core PID
Core storage location: `/var/lib/systemd/coredump/`.
3. Enable core dumps (macOS)
# macOS uses /cores by default (must be root-writable) ulimit -c unlimited # Check ls /cores/ # launchd-launched services: set in plist # <key>HardResourceLimits</key> # <dict><key>Core</key><integer>9223372036854775807</integer></dict>
4. Analyse a core with GDB
# Load binary and core gdb ./prog core.12345 # If the binary was stripped, provide the unstripped copy gdb ./prog-with-symbols core.12345 # Essential first commands (gdb) bt # call stack (gdb) bt full # stack + locals (gdb) info registers # CPU state at crash (gdb) frame 2 # jump to interesting frame (gdb) info locals # local variables in frame (gdb) print ptr # inspect a pointer # All threads (multi-threaded crash) (gdb) thread apply all bt full
5. Analyse a core with LLDB
lldb ./prog -c core.12345 # Or lldb (lldb) target create ./prog --core core.12345 # Commands (lldb) bt (lldb) thread backtrace all (lldb) frame select 2 (lldb) frame variable
6. Missing symbols: debuginfod
`debuginfod` serves debug symbols from a central server, mapping build IDs to DWARF data.
# Install client (Debian/Ubuntu) sudo apt install debuginfod # Enable (add to ~/.bashrc or /etc/environment) export DEBUGINFOD_URLS="https://debuginfod.ubuntu.com https://debuginfod.elfutils.org" # GDB auto-fetches symbols when DEBUGINFOD_URLS is set gdb ./prog core # Manually query debuginfod-find debuginfo <build-id> debuginfod-find source <build-id> /path/to/file.c
7. Missing symbols: manual approach
# Check if binary has a build ID readelf -n ./prog | grep Build # Find the correct debug package # Debian: apt install prog-dbg or prog-dbgsym # RPM: dnf install prog-debuginfo # Point GDB to debug symbols directory (gdb) set debug-file-directory /usr/lib/debug # Or use eu-readelf to dump build ID, then find .debug file eu-readelf -n ./prog find /usr/lib/debug -name "*.debug" | xargs eu-readelf -n 2>/dev/null | grep <build-id>
8. Strip binaries and keep symbols
Best practice: build with symbols, strip for distribution, keep an unstripped copy.
# Build gcc -g -O2 -o prog main.c # Separate debug info objcopy --only-keep-debug prog prog.debug objcopy --strip-debug prog prog.stripped # Add a debuglink so GDB finds the debug file automatically objcopy --add-gnu-debuglink=prog.debug prog.stripped # Deploy prog.stripped; keep prog.debug in a symbols store indexed by build-id
9. Quick triage from core without full debug session
# Print backtrace non-interactively gdb -batch -ex 'bt full' -ex 'thread apply all bt full' ./prog core 2>&1 | tee crash.txt # Print registers gdb -batch -ex 'info registers' ./prog core # Check signal that caused crash gdb -batch -ex 'info signal' ./prog core
For a full cheatsheet covering core pattern tokens, coredumpctl, GDB/LLDB commands, debuginfod servers, and strip/symbol workflows, see [references/cheatsheet.md](references/cheatsheet.md).
Related skills
- Use `skills/debuggers/gdb` for full GDB session details
- Use `skills/debuggers/lldb` for LLDB-based analysis
- Use `skills/runtimes/sanitizers` to catch the bug before it reaches production
- Use `skills/binaries/elf-inspection` for `readelf`, build IDs, and binary inspection
A curated suite of AI agent skills for systems and low-level programming — C/C++, Rust, Zig, GPU, bare-metal firmware, Linux kernel/driver development, computer architecture, compiler internals, HPC, and more.
Repo: mohitmishra786/low-level-dev-skills
Other skills on low-level-dev-skills.
- /custom-allocators
Custom allocator skill for memory allocation strategies. Use when implementing pool/slab/arena allocators, tuning jemalloc/mimalloc, writing Rust GlobalAlloc, or benchmarking allocator performance. Activates on queries about jemalloc, mimalloc, tcmalloc, arena allocator,
Open skill - /numa-programming
NUMA programming skill for multi-socket memory locality. Use when detecting NUMA topology, binding processes with numactl, using libnuma API, building NUMA-aware data structures, or measuring remote access penalties. Activates on queries about numactl, libnuma, NUMA topology,
Open skill - /af-xdp
AF_XDP skill for high-performance XDP sockets. Use when creating AF_XDP sockets, configuring UMEM and XSK rings, XDP_REDIRECT programs, copy vs zero-copy mode, or comparing with DPDK. Activates on queries about AF_XDP, xsk_umem, XDP_REDIRECT, libbpf xsk, or zero-copy XDP.
Open skill - /dpdk
DPDK skill for userspace packet I/O. Use when initializing EAL, configuring PMD drivers, using mbuf pools and rte_ring, setting up huge pages, RSS, or testpmd validation. Activates on queries about DPDK, EAL, rte_eth_rx_burst, hugepages, PMD, or testpmd.
Open skill - /io-uring
io_uring skill for Linux async I/O. Use when building high-performance servers with liburing, multi-shot operations, provided buffers, fixed files, zero-copy send, or tokio-uring. Activates on queries about io_uring, SQE/CQE, liburing, IORING_OP_PROVIDE_BUFFERS, or io_uring vs
Open skill - /adc-dac-baremetal
Bare-metal ADC and DAC skill. Use when configuring analog sampling, DMA-driven ADC, calibration, or DAC output on MCUs. Activates on queries about ADC bare-metal, sampling time, DMA ADC, or DAC channel setup.
Open skill

