re-crash-triage

Reproduce, minimize, and root-cause program crashes using ASAN, gdb, rr, and afl-tmin.

64|9|Updated Aug 17, 2026
One-click install
npx skills add https://github.com/dslsdzc/rev-skills --skill re-crash-triage-dslsdzc
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: re-crash-triage
Source: https://github.com/dslsdzc/rev-skills/tree/main/.claude/skills/re-crash-triage
Command: npx skills add https://github.com/dslsdzc/rev-skills --skill re-crash-triage-dslsdzc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Fuzzing and testing produce crash inputs, but turning a raw crash into a confirmed, minimal, root-caused vulnerability report requires a disciplined workflow. This Skill guides deterministic reproduction, sanitizer report interpretation, input minimization, debugger-based root-cause analysis, and PoC production. ## Core Features & Use Cases - Deterministic Reproduction: Verify crashes across repeated runs, enable core dumps, and distinguish deterministic crashes from non-deterministic ones caused by races, uninitialized memory, or ASLR. - ASAN/UBSAN Report Interpretation: Decode heap-buffer-overflow, use-after-free, double-free, and SEGV reports, tracing freed-by and allocated-by stacks to locate the fault. - Input Minimization & Root Cause: Shrink crash inputs with afl-tmin/afl-cmin, then use gdb backtraces or rr record/replay with reverse-continue to pinpoint the root cause. - Use Case: A fuzzer drops 50 crashing inputs in out/crashes/. Use this Skill to deduplicate them, minimize each to a smallest reproducer, confirm reachability of the crash path, and produce a PoC with sha256, reproduction steps, and impact assessment. ## Quick Start Analyze this crash input from my fuzzing run, minimize it, and produce a root-cause report with a minimal PoC.

Frequently Asked Questions about re-crash-triage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I analyze a crash input from fuzzing?▼

First reproduce the crash deterministically by running the target with the input three times, then minimize it with afl-tmin while preserving the crash. Use gdb backtraces and ASAN reports to locate the faulting function and determine the root cause.

How to minimize a crashing test case with afl-tmin?▼

Run afl-tmin -i crash_input -o crash.min -- ./target @@ to shrink the input while preserving the crash. Use afl-cmin first to deduplicate multiple crash inputs by execution path, then manually trim bytes to verify the minimal boundary.

What do ASAN error types like heap-use-after-free mean?▼

heap-use-after-free means memory was accessed after being freed; check the freed-by and allocated-by stack traces to find the release and reuse points. heap-buffer-overflow indicates out-of-bounds reads or writes, with the report showing direction and offset.

How do I debug non-deterministic crashes that only happen sometimes?▼

Use rr to record the execution with rr record ./target input, then replay with rr replay and reverse-continue to step backward from the crash to the root cause. Also disable ASLR in gdb with set disable-randomization on to rule out address randomization.

Why is no core dump file generated after a segfault?▼

Even with ulimit -c unlimited, the kernel core_pattern may route cores to systemd-coredump or apport. Check /proc/sys/kernel/core_pattern and temporarily set it to core, or run the target directly under gdb instead of relying on core files.

Does an ASAN crash always mean a real exploitable vulnerability?▼

No. ASAN reports potential bugs that may be in unreachable code, introduced by the fuzzing harness, or only triggered under sanitizer builds. Confirm reachability with gdb backtraces and disassembly, and verify behavior in release builds before claiming a vulnerability.