Skip to main content
← All terms
Glossary

Crash Deduplication

The process of grouping distinct crash inputs that trigger the same underlying bug into a single unique report.

A fuzzing campaign against a target with one real bug may produce thousands of inputs that all trigger the same crash. Without deduplication, engineers drown in duplicate reports rather than unique bugs. Crash deduplication groups crashes by their root cause, typically by comparing sanitized stack traces: two crashes are considered duplicates if their top N stack frames match. More sophisticated approaches compare the crash address, fault type (read vs. write, stack vs. heap), or use sanitizer output like AddressSanitizer's allocation and deallocation traces to distinguish overlapping bugs. Deduplication is not a solved problem — imperfect heuristics both merge distinct bugs (undercounting) and split variants of the same bug (overcounting). A practical system errs toward splitting (showing more unique groups) and lets humans merge obvious duplicates.

Related

Triage
The workflow of reviewing, prioritizing, and reproducing crashes found by a fuzzer to determine exploitability and root cause.
Reproducer
A minimal input (and the command to run it) that reliably triggers a specific crash or bug found by the fuzzer.
AddressSanitizer (ASan)
A fast memory-error detector that catches heap/stack buffer overflows, use-after-free, and similar bugs at runtime.
Fuzz Testing
Automated software testing that generates many semi-random inputs to find crashes, hangs, and security vulnerabilities.
AFL++
A community-maintained, highly optimised fork of American Fuzzy Lop that is the most widely deployed coverage-guided fuzzer.