OSS-Fuzz revision
Switch to the exact oss-fuzz_sha recorded for the case.
Reproducible Failure Cases
Each case records the metadata needed to initialize the OSS-Fuzz environment and reproduce the observed failing build, including the OSS-Fuzz revision, upstream revision, base image digest, fuzzing engine, sanitizer, architecture, and archived build log.
Error taxonomy
Failure categories follow the 25 fine-grained root causes reported in My Fuzzers Won't Build: An Empirical Study of Fuzzing Build Failures.
Language Distribution
Computed from the current dataset file.
Error Categories
Fine-grained RC labels normalized before aggregation.
Reproduction lock
A case is reproducible only when the source tree and build environment are pinned together. Use the values in each record as immutable inputs before running the failing build.
Upstream revision
Clone software_repo_url, then check out the exact software_sha.
Dockerfile inputs
Inspect the project Dockerfile in OSS-Fuzz or upstream. Pin FROM to the recorded base_image_digest.
Clone source
Update any Dockerfile git clone URL and checkout to match software_repo_url and software_sha.
Important: the Dockerfile may be maintained by OSS-Fuzz
or by the upstream project. If a Dockerfile pins a different source or
base image, treat it as part of the reproduction setup and align it
with the case metadata before building.
Dataset Cases
Search by project, language, repository, SHA, error category, or build log. Links and hashes are shortened in the table and expanded in the details view.
| Project | Language | Failure Date | OSS-Fuzz SHA | Build Log | Upstream Repo | Engine | Sanitizer | Arch | Error Category |
|---|
Metadata Schema
Public records omit the repair outcome field and retain the reproducibility metadata needed for auditing and benchmark execution.