Fuzz testing basics: coverage-guided inputs, corpora and crash triage

What it is

Fuzzing feeds a program generated inputs to find crashes, hangs and violated assertions. Modern fuzzers are coverage-guided: the Go documentation describes an engine that mutates inputs, keeps those that reach new code as "interesting" additions to a corpus, and reports failing inputs after minimising them. A fuzz target is a small function that takes bytes or typed arguments and calls the code under test. The libFuzzer documentation states that the corpus should ideally be seeded with a varied collection of valid and invalid inputs and that the fuzzer works without seeds but less efficiently. OSS-Fuzz runs fuzzers continuously for open-source projects with the libFuzzer, AFL++, Honggfuzz and Centipede engines combined with sanitizers.

Why it matters

Parsers, decoders, protocol handlers and anything else that touches untrusted bytes have edge cases people do not enumerate: length fields that overflow, structures that nest deeper than the stack, encodings that switch mid-stream. A fuzzer explores them mechanically, and with sanitizers it detects memory errors that would otherwise pass silently. In memory-safe languages the payoff is panics, infinite loops, resource exhaustion and broken invariants.

How to apply

• Choose targets where input is untrusted and the code is fast and deterministic; the Go documentation asks for targets that do not depend on global state because they run in parallel workers.
• Write the target as a property check, not only "does not crash": round-trip (decode(encode(x)) == x), compare against a reference implementation, or assert invariants after the call.
• Seed the corpus with real samples and commit it; commit every minimised crash input as a regression test (Go writes failing inputs to testdata/fuzz/ and runs them with ordinary go test).
• Give CI a short budget (a time or iteration limit) and run long sessions on a schedule or through a service such as OSS-Fuzz; minimise the corpus periodically (-merge=1 in libFuzzer) so it stays small without losing coverage.
• Build C and C++ targets with address and undefined-behaviour sanitizers.

Pitfalls

A target that reads files or the network, or that is slow, starves the engine. Fuzzing finds crashes, not wrong answers, unless the target asserts something. Non-deterministic targets produce reports nobody can reproduce. The Go documentation notes a timeout of 1 second per execution, so a slow but legitimate path is reported as a hang. A fuzzer never proves absence of bugs; it lowers the odds of the kinds it can trigger.