arXiv CS open access

Keeping Fuzzers on Duty: Repairing Fuzzing Build Breakages in Continuous Open-Source Fuzzing

Zhuang Zhao et al. · arxiv_cs

arXiv CS · Papers

software-architecture software-engineering testing

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

arXiv:2611.06358v1 [cs.SE] 4 Nov 2026

Keeping Fuzzers on Duty: Repairing Fuzzing Build Breakages in Continuous Open-Source Fuzzing Zhuang Zhao∗

Jiongchi Yu∗

Yao Zhang†

Dongge Liu

Tianjin University Tianjin, China zhaozhuang@tju.edu.cn

Nanyang Technological University Singapore jiongchiyu@acm.org

Tianjin University Tianjin, China zzyy@tju.edu.cn

Google Australia donnggeliu@google.com

Qiang Hu

Xiaohong Li†

Yang Liu

Tianjin University Tianjin, China qianghu@tju.edu.cn

Tianjin University Tianjin, China xiaohongli@tju.edu.cn

Nanyang Technological University Singapore yangliu@ntu.edu.sg

Abstract

Keywords

Continuous fuzzing platforms such as OSS-Fuzz provide sustained security testing for open-source projects, but long-term build breakages reduce security coverage and waste infrastructure resources. In OSS-Fuzz, around 20% of integrated projects stay in build-failure states, leaving their fuzzers effectively off duty. These failures expose a critical maintenance gap between platform maintainers, who lack project-specific context, and project maintainers, who often lack fuzzing and infrastructure expertise. Existing program-repair techniques cannot be directly applied as fuzz build breakages span evolving project and infrastructure artifacts. They require repeated infrastructure-aware diagnosis rather than localized code edits, making them difficult to repair successfully. We present FuzzMedic, an automated agent for fuzz build repair. FuzzMedic performs evidence-guided diagnosis to identify repair opportunities across project and fuzzing-infrastructure artifacts. It then conducts repair exploration over a repair-state graph (RSG), which captures the evolving workspace and builds feedback throughout the repair process. By supporting branching and rollback, the RSG enables FuzzMedic to recover from unproductive repair paths during long-horizon system-level debugging. FuzzMedic further validates candidate patches to ensure that they restore executable fuzz targets rather than merely suppress build failures. We evaluate FuzzMedic on 128 reproducible OSS-Fuzz build failures extracted from 1, 820 real-world failures. FuzzMedic achieves a 48.44% repair rate and outperforms three representative programrepair baselines. We further deploy FuzzMedic on real-world OSSFuzz failures, where it repairs 29 real-world OSS-Fuzz cases that have been merged by upstream maintainers, including 3 longstanding failures that had remained unresolved for more than one year and 2 cases that had never built successfully.

Fuzz build repair, fuzzing, automated program repair, LLM-based agents, build-log-driven repair

Introduction

Continuous fuzzing services keep testing open-source software as projects evolve. In OSS-Fuzz, project-specific integrations build instrumented targets inside containers and deliver executable fuzzers to the testing infrastructure [8, 11, 29]. When this build fails, the affected configuration cannot supply newly built fuzz targets. Repairing OSS-Fuzz build failures is therefore necessary to maintain continuous security testing, even when the project still builds successfully outside the fuzzing environment. OSS-Fuzz-specific evidence establishes the maintenance problem. Nourry et al. analyze more than 1.2 million OSS-Fuzz build logs and characterize failures involving project code, dependencies, fuzzing environments, Docker environments, and external resources [25]. Our collected cases similarly require reasoning about upstream revisions alongside OSS-Fuzz build scripts, toolchains, and sanitizer settings. The operational difficulty is the split between projectspecific build knowledge and platform integration knowledge. This motivates repair assistance across both workspaces. It does not establish that every compilation error is intrinsically specific to fuzzing. Existing build-repair systems address important parts of this problem. BuildMedic targets Maven dependency breakage, CXXCrafter targets general C/C++ software building, and CompileAgent automates repository-level compilation [14, 22, 38]. Their reported results concern different tasks and datasets and are not directly comparable with OSS-Fuzz repair rates. Generic repository-repair systems also offer useful localization and search strategies [2, 33]. In our setting, however, the actionable change may lie outside the upstream repository, and repair must satisfy container, instrumentation, and fuzz-target validation constraints. Three practical demands guide our design. First, a compiler or linker message identifies a symptom, while the responsible change may lie in another workspace or dependency. Second, failures before a runnable target exists provide build feedback rather than crashtriggering inputs. Third, patch attempts modify the workspace.

CCS Concepts • Software and its engineering → Software maintenance tools; Software testing and debugging. ∗ Zhuang Zhao and Jiongchi Yu contributed equally to this work. † Corresponding authors: Yao Zhang and Xiaohong Li.

Fuzz Build Failure OSS-Fuzz Maintainer

Config

Fuzzing Build Code

Developer

C2:No Fuzzer C3:Dual Workspace Binary Fault Localization Patch Generation

What Project? What Fuzz?

and sanitizer configurations. The platform builds and validates executable targets before fuzzing. A failure at this prerequisite prevents downstream feedback from newly built targets. OSS-Fuzz [8] is a representative centralized platform for opensource software. It improves the security and stability of common open-source software by combining modern fuzzing techniques with scalable distributed execution [29]. Its workflow builds project container images, compiles fuzz targets under specified sanitizer, engine, and architecture settings, and validates the generated fuzzers before continuous fuzzing begins [11]. ClusterFuzzLite [9] integrates fuzzing with continuous integration and continuous delivery (CI/CD). Code Intelligence provides CI Fuzz integration examples for CMake and JUnit [5]. Our evaluation is based solely on OSS-Fuzz.

Open-Source Repository

Build Config Source Code

Coding

Validation

... C1:Multilingual

C4:Expensive Building

Figure 1: Overview of fuzz build repair in OSS-Fuzz.

2.2

Clearing an early error can expose a later error, while an unsuccessful edit can damage previously working stages. Repeated full builds make indiscriminate patch sampling costly. Section 2 illustrates these demands with two repair trajectories. We present FuzzMedic, implemented as collaborating agents using Google ADK. It connects Evidence-Constrained Root-Cause Localization (ECRCL), Failure-Guided Repair Knowledge (FGRK), Reflection Summary and Memory Curation (RSMC), and Hierarchical Stateful Rollback (HSR). The contribution is their integration around observable OSS-Fuzz build states. Localization constrains candidate changes, templates encode domain constraints, memory records validated outcomes, and rollback preserves recoverable workspaces. We evaluate this system on 128 reproducible failures from 113 projects. The reported configuration repairs 62 cases (48.44%), versus 27 (21.09%) for the strongest native-budget baseline. Different native budgets limit causal interpretation of this gap. Supplementary comparisons use matched token/time caps or limited subsets. Separately, 29 generated patches were merged into upstream or OSS-Fuzz main branches after human verification and maintainer review. The workflow was also exercised through a pull request (PR) experiment in oss-fuzz-gen. This demonstrates an experimental integration rather than production adoption. The paper makes the following three contributions. • A reproducible OSS-Fuzz build-repair task and benchmark, with pinned failure contexts, explicit selection criteria, language distributions, and category-level outcomes. • An ADK-based multi-agent repair system combining crossworkspace evidence, repair knowledge, trajectory memory, and recoverable build-state exploration. • An evaluation of repair effectiveness and resource use. In collaboration with Google, we integrate FuzzMedic into an oss-fuzz-gen PR experiment and produce 29 maintainer-merged patches across 28 projects.

Automated Build Repair for Fuzzing

Figure 1 summarizes the task, from dual-workspace fault localization to patch generation and build validation. BuildMedic repairs Maven dependency failures, while CXXCrafter automates general C/C++ builds [22, 38]. OSS-Fuzz additionally requires compatible instrumentation, integration artifacts, and target validation. Our focus is the repair of OSS-Fuzz fuzzing-build failures before a runnable target is available. Existing work on OSS-Fuzz and automated repair addresses adjacent tasks. Nourry et al. [25] characterize and classify build failures but do not generate patches. Zhang et al. [41] use OSS-Fuzz vulnerability reports to repair security bugs, assuming that a successful fuzzing campaign has already produced crash inputs. Kim et al. [17] connect fuzzing and automated program repair (APR) at the patch-search level rather than the build-maintenance level. This gap motivates a repair system designed for OSS-Fuzz fuzzing build failures.

2.3

Motivation Example

To illustrate the additional constraints encountered in this setting, we analyze two OSS-Fuzz failures where Agentless, CompileAgent, and SWE-Search fail but FuzzMedic succeeds. Root-Cause Evidence in jimfs. The build log reports a Java classversion mismatch. Error Prone was compiled for Java 21 with class file version 65.0, while the OSS-Fuzz configuration uses Java 17 with version 61.0. Several repairs appear plausible, including source edits, Java Development Kit (JDK) upgrades, and dependency downgrades. The identified cause is an upstream change from errorprone.version 2.42.0 to 2.43.0, which introduces an annotation processor incompatible with this JDK profile. The baselines identify the symptom but miss the responsible commit. FuzzMedic localizes that commit and generates a compatible fix in one round. State-Aware Repair in toml_edit. The toml_edit failure requires sequential repair. A Docker WORKDIR /src directive conflicts with the local checkout mechanism and prevents source retrieval. Fixing checkout exposes a Rust linker failure involving unresolved sanitizer-coverage symbols such as __sancov_gen_* under AddressSanitizer (ASan). The baselines alternate between these failures without preserving solved subproblems. FuzzMedic uses RSMC to retain round-level progress, FGRK to retrieve an OSS-Fuzz-specific WORKDIR rule, and HSR to recover from regressive branches. This preserves checkout progress during linker repair.

2 Background 2.1 Continuous Fuzzing Platforms Fuzzing searches for security and stability defects through generated inputs [23]. Continuous services automate instrumented builds, execution, and reporting. Developers supply targets, scripts, 2

Table 1: Sequential benchmark selection. Exclusions are counted at the first applicable stage.

These trajectories motivate combining evidence-guided localization, repair knowledge, and state recovery.

Dataset Construction

Stage

Controlled repair evaluation requires reconstructing the historical build context, not merely collecting error messages. We therefore construct a curated benchmark for build failure repair and controlled evaluation. Following the taxonomy of Nourry et al. [25], we collect 1, 820 build failure logs from the OSS-Fuzz public buildstatus portal and log storage [10]. We reproduce each candidate by restoring the recorded failure-time repositories and build environments, and retain 128 reproducible cases from 113 projects.

3.1

Failure Collection

Selection and Reproducibility

Candidate evaluation records are archived build-failure logs, maintained separately from FGRK’s historical failure-and-repair source records. Their collection windows coincide. Independence is established by FGRK’s project and related-incident exclusions, not by assuming distinct collection dates. We first merge records confirmed to arise from the same underlying breakage, removing 1,076 duplicates and retaining 744 representatives. Identical error text alone is insufficient to merge records. Unresolved relationships remain separate. We then require extractable logs and metadata and initially accessible version references and resources, excluding 256 records and retaining 488. A historical fix is not required for inclusion. Finally, we pin the OSSFuzz and upstream commits, base-image digest, and dependency commit identifiers, restore the historical environment, and replay the Docker build. Inclusion requires the original diagnostic and failure stage, confirmed manually. This excludes 360 records whose resources or environment cannot be recovered or whose original failure cannot be reproduced. Table 1 reports mutually exclusive exclusions. Of the 1,692 records not retained, only 360 fail the historical restoration or replay. The remainder are duplicates or fail metadata checks. The resulting 128 cases form a controlled-replay benchmark, not a representative sample of all OSS-Fuzz build failures. Appendix B details the audit requirements.

3.3

Retained

— 1,076 256 360

1,820 744 488 128

Total excluded

1,692

Table 2: Metadata schema for each dataset case.

The collected logs span December 29, 2022 to June 14, 2026. We collected 1, 820 build failure logs from the OSS-Fuzz public buildstatus portal [10], which links to archived failure logs. For each candidate, we restored the OSS-Fuzz repository, upstream project, and third-party dependencies to the recorded failure-time versions, re-executed the fuzz-build pipeline in Docker, and retained the case only when the reproduced failure matched the original error message and failure stage.

3.2

Excluded

Collected logs Incident deduplication Metadata checks Historical replay

Field

Description

project language error_time oss-fuzz_sha fuzzing_build_error_log software_repo_url software_sha engine sanitizer architecture base_image_digest error_category root_cause_commit root_cause_workspace fixed_state

Project name Primary programming language Date of the observed build failure OSS-Fuzz commit identifier at failure time Link to the original OSS-Fuzz build log Link to the upstream open-source repository Upstream project commit identifier at failure time Configured fuzzing engine Sanitizer configuration, e.g., address Target processor architecture Digest of the OSS-Fuzz base Docker image Failure category per [25] Commit identified as the root cause of the build failure Workspace where the root cause is located Whether the case is repaired by the evaluated system

failure-time inputs available to the agent. Reference fixes and postfailure repair history are excluded from agent-accessible snapshots and tools. Labels and provenance remain audit-only.

3.4

Failure Taxonomy and Distribution

We classify the 128 cases using the root-cause (RC) taxonomy of Nourry et al. [25], which defines 25 root causes grouped into 11 generic categories. Each category is specified by diagnostic criteria, representative build-log patterns, and boundary examples. Annotation Procedure. Three authors annotated all 128 cases following Nourry et al. [25]. For each case, annotators inspected the build log, failure metadata, and failure-time repository state, and assigned one RC category. When the log was insufficient, they further examined the project repository, OSS-Fuzz issue tracker, related pull requests, and commit history. For logs with multiple failure patterns, we used the first fatal diagnostic for classification because later errors are often cascading effects. Annotation proceeded through calibration, independent labeling, and adjudication. All annotators first labeled the same 30 random cases to align category boundaries. The remaining 98 cases were then double-labeled and disagreements were resolved by the full panel. Fleiss’ 𝜅 on the calibration set was 0.76, indicating substantial agreement. All 128 cases were classified, with none marked as insufficient evidence. Taxonomy Distribution. Our dataset covers nine of the 25 RC categories in [25]. For brevity, we denote these benchmark-local categories as RC1 to RC9 while preserving their definitions. Table 8 reports the distribution of the 128 cases.

Metadata Schema

Each dataset entry is a structured record in YAML Ain’t Markup Language (YAML) format. It contains the context needed to restore the environment and reproduce the failure (Table 2). Root-cause annotations and outcome labels are evaluation data, separate from the

RC1 and RC2 dominate the dataset, accounting for 87.50% of cases. Compilation and dependency labels cover both ordinary build problems and integration-specific constraints. The remaining 12.50% of cases span seven smaller categories, each below 5%. Case Status. All case-status statistics were collected before June 15, 2026. We divide the 128 cases into two groups. SolvedCases contains 60 failures that had been repaired and successfully validated before this date. RealWorldCases contains 68 failures that remained active in the collected OSS-Fuzz records. This status split distinguishes known-fix and then-unresolved cases. Language Distribution. The seven labels include the Java Virtual Machine (JVM) ecosystem. Their counts are C++ (45), JVM (21), C (19), Python (18), Rust (12), Go (11), and Swift (2), totaling 128 cases. C and C++ are separate labels. Multiple incidents can belong to one project, so cases are not necessarily statistically independent. Section 5.2.1 reports repair rates by category. Benchmark Value and Scope. Following Build-bench [42], the benchmark couples failure-time build contexts with executable verification. It targets continuous-fuzzing integration and covers nine of the 25 root-cause categories.

ECRCL uses a two-tier localization strategy inspired by the change-inducing-fix analysis of Śliwerski, Zimmermann, and Zeller [44]. Precise Tracking extracts file paths and line numbers from diagnostics and applies git blame to identify the responsible commit. Temporal Fallback handles logs without file-line evidence, including dependency-resolution and Docker failures. It retrieves commits from both repositories within one day before or after the failure and treats their modified files as suspects. Evidence Consistency Optimization. ECRCL refines candidates through PageRank-style bounded message passing over a directed heterogeneous evidence graph 𝐺 = (𝑉 , 𝐸,𝑊 ). The node set 𝑉 contains the primary failure region, program and build entities, and candidate commits. Entities include files, lines, diff hunks, and dependencies. The edge set 𝐸 encodes directed evidence relations, while 𝑊 assigns each edge (𝑢, 𝑣) a non-negative strength 𝑤 (𝑢, 𝑣). Relations connect failure regions to files and files or lines to commits. Let 𝐶 denote the candidate commit set and 𝑁 region the primary failure-region node. ECRCL initializes the evidence distribution from the primary failure region, with 𝑃 0 (𝑁 region ) = 1 and 𝑃 0 (𝑢) = 0 for all other nodes. For a node 𝑢, let N + (𝑢) and N − (𝑢) denote its outgoing and incoming neighbors, respectively. Edge weights are normalized into transition probabilities. 𝑤 (𝑢, 𝑣) Pr(𝑢 → 𝑣) = Í . (1) 𝑘 ∈ N + (𝑢 ) 𝑤 (𝑢, 𝑘)

Design of FuzzMedic

FuzzMedic repairs OSS-Fuzz builds through collaborating agents (Figure 2). ECRCL localizes candidate causes from logs and permitted repository history. FGRK supplies repair constraints before patch generation. Each applied patch is checked in the containerized build environment. RSMC retains validated outcomes as compact memory, while HSR tracks physical workspace states and recovers from unproductive branches. Diagnosis, knowledge, validation, memory, and state recovery thus form an iterative loop across upstream and OSS-Fuzz artifacts.

4.1

ECRCL then performs bounded message passing for 𝑇 iterations. ∑︁ 𝑃𝑡 (𝑢) = (1 − 𝑑)𝐼 (𝑢) + 𝑑 Pr(𝑣 → 𝑢)𝑃𝑡 −1 (𝑣), (2) 𝑣 ∈ N − (𝑢 )

where 𝑃𝑡 (𝑢) is the relevance mass of node 𝑢 after iteration 𝑡, 𝑑 ∈ (0, 1) is the damping factor, and 𝐼 (𝑢) is the restart vector with 𝐼 (𝑁 region ) = 1 and 𝐼 (𝑢) = 0 for all other nodes. To suppress false positives from incompatible build environments, ECRCL applies a gating coefficient 𝑀 (𝑐𝑖 ) ∈ [0, 1] to each candidate commit 𝑐𝑖 ∈ 𝐶. This coefficient summarizes compatibility with the current sanitizer, architecture, compiler, and toolchain configuration. The final score is

Evidence-Constrained Root-Cause Localization

Before patch generation, FuzzMedic must decide where the observed build failure should be repaired. This is non-trivial because the visible compiler, linker, or dependency error may be only a symptom, while the actionable fix may lie in another repository or configuration artifact. ECRCL addresses this problem by localizing the causal commit of a fuzzing build failure using only the build log and failure timestamp, without binary artifacts, coverage feedback, or runtime traces. Fault Evidence Abstraction. ECRCL abstracts the build log into a primary fault evidence region, which captures the earliest fatal diagnostic and filters cascading diagnostics. Candidate Commit Space Construction. ECRCL builds an observation-constrained candidate set using spatial correlation, temporal proximity, and repair-scope determination. Spatial correlation retains commits that modify fault-relevant files, build configurations, dependency specifications, or structural code elements. Temporal proximity considers commits around the failure timestamp, reflecting that most OSS-Fuzz build failures are triggered by recent changes in upstream code, OSS-Fuzz configurations, or shared dependencies [25]. Repair-scope determination estimates whether the failure originates from the upstream source or downstream fuzz-build configuration workspace.

𝑆𝑐𝑜𝑟𝑒 (𝑐𝑖 ) = 𝑀 (𝑐𝑖 ) 𝑃𝑇 (𝑐𝑖 ),

(3)

Candidate scores are sorted in descending order. The reported main experiment selects the top-ranked candidate (𝑘 = 1) for counterfactual verification. An optional top-three verification mode is available but is not used for these reported results. No minimum-score or score-gap threshold is used. If no selected candidate passes verification, localization returns UNKNOWN. Fixed Settings. Propagation uses 𝑑 = 0.85 and 𝑇 = 3. Edge weights are 1.0 for message-to-commit links, 1.1 for fault-region links to messages containing error/fail/fix, 1.3 for matching file nodes, and 1.5 for blame-anchor links to commits. Temporal file-tocommit links use 𝑤𝑡 below. Environment compatibility is binary, 𝑀 ∈ {0, 1}; the candidate cutoff is 𝑘 = 1, and HSR’s neutral tolerance is 𝜃 = 2. The temporal weight is 𝑤𝑡 = max(0.1, 1.5 2−Δ𝑡 /86400 ),

(4)

FuzzMedic

Typical Continuous Fuzzing Workflow

① Evidence-Constrained Root Cause Localization Error Time Extraction

Developer

Upstream Repository Code

Maintainer

FAIL∧PASS Counterfactual Validation

Candidate Commit Screening

③Patch Generation

② Failure-Guided Repair Knowledge

Cloud Fuzz Fail Cluster

Historical Repair Corpus

Advancing Path

Stagnant Path

0 +

+ Repair Proximity Metric Final State

+ +

Regressive Path State Rollback

Solver Agent

Patch

+++

Finalization

+ +

+ + p4

0 +

p1 +

+ p2

FAIL

State Preserved Rollback

Memory Curation

Degraded State Rollback

Validation

④Reflection Summary&

⑤Hierarchical Stateful Rollback

Initial Fix State

pi Patchi Apply

Error Report

... Error-Evidence Matching

Buggy Location

PASS

Error type:... Keyword:”...”

Scrape

OSS-Fuzz Config

Continuous Fuzzing

Top-1 Parent

Error Evidence Extraction

Preliminary Exploration

Reflector Repair Trace Record Agent

Figure 2: Overview of the FuzzMedic architecture. Evidence localization, template-guided patch generation, Docker validation, trajectory memory, and state recovery form an iterative repair loop. where Δ𝑡 is the absolute commit/failure time difference in seconds. Outgoing weights are normalized before propagation. Ranked candidates are hypotheses, not confirmed causes. Counterfactual Verification. ECRCL verifies ranked candidates through counterfactual build replay under the same OSS-Fuzz configuration. A commit is confirmed only if the parent revision builds, reapplying the candidate reproduces the observed build failure, and the reproduced failure matches the original primary fault evidence in both failure stage and diagnostic signature. The verified result is stored as a root-cause attribution artifact for patch generation.

4.2

error type or build principle alone does not constitute incident overlap. Knowledge Construction. The strict knowledge base is regenerated only from retained sources. Removing project names from mixed-source templates is insufficient. A large language model (LLM) assists extraction of failure patterns, applicability conditions, diagnoses, and general repair actions. Two authors independently review technical correctness, provenance, and case specificity. The result contains 43 error-pattern entries (ERR) and 13 reusable guideline entries (GL), totaling 56. Each entry retains its source mapping, but runtime templates omit evaluation incident identifiers, reference patches, and case-specific repair instructions. Reference fixes and source evidence remain in an audit environment inaccessible to the Solver agent, which generates candidate patches. This provides project-level separation with related-incident checks. It is not a temporal split preceding all evaluation cases. Reusable Patterns Across Projects. The pffft, varnish, and netcdf repairs correct the same Dockerfile pattern, where a COPY instruction with multiple sources lacks the destination’s trailing slash. These cases illustrate how a general build constraint can recur across projects. FGRK captures such diagnostic conditions and repair principles, while its source-selection procedure separately excludes evaluation projects and related incidents. This distinguishes reusable build knowledge from transferring a case-specific reference patch. A shared failure category can nevertheless require different repairs. The maven, airflow, and mdbook-i18n-helpers cases are all dependency-related. The first requires a newer Maven version for plugin compatibility. The second requires a local development package version to be available during dependency resolution. The third updates a pinned nightly toolchain to handle a manifest requiring Rust Edition 2024. These examples connect the category-level labels to different actionable constraints. FGRK records applicability conditions and repair actions so guidance can be selected from the

Failure-Guided Repair Knowledge

After localization, the agent still needs repair knowledge that is often absent from raw logs. OSS-Fuzz builds impose constraints on container layout, sanitizer instrumentation, fuzzing engines, dependency setup, and fuzz-target packaging, so the same error message may require a fuzzing-specific fix rather than a generic build edit. FGRK addresses this gap by retrieving historically validated repair knowledge based on the current failure pattern and using it to guide patch generation. Project and Incident Separation. FGRK sources cover December 29, 2022 to June 14, 2026, the same window as the benchmark. The cutoff applies to the actual failure and repair content used, including archived versions of evolving pages. Later additions and unverifiable versions are excluded. From 1,940 candidate source records, completeness/time checks and incident deduplication yield 502 historical failures from 210 normalized projects. Excluding all 253 records from the 86 source projects matching any of the 113 evaluation projects leaves 249 failures from 124 projects. Checks of forks, mirrors, shared upstreams, and patch propagation then remove 42 records from 14 related projects and seven additional same-origin incidents. A final provenance review excludes 12 records, leaving 188 failures from 110 projects (Appendix B.4). Sharing a generic 5

Table 3: FGRK construction and source-selection ledger. Exclusions are sequential and non-overlapping. Initial materials become incident records after deduplication. The count 238 denotes preliminary project identifiers. Stage Initial failure/repair candidate collection Time, completeness and version checks Incident deduplication and project normalization Exclude all records from evaluation projects Related-repository and sameorigin-incident audit Final source-traceability review Total excluded / final retained

Algorithm 1: HSR rollback decision policy Input: Repair-state graph G , nodes 𝑛𝑝𝑟𝑒𝑣 , 𝑛𝑐𝑢𝑟 , neutral tolerance 𝜃 = 2 Output: Decision 𝑎 , next-round initial state 𝑛𝑖𝑛𝑖𝑡 𝑆𝑝𝑟𝑒𝑣 ← ⟨𝐿 (𝑛𝑝𝑟𝑒𝑣 ), 𝑉 (𝑛𝑝𝑟𝑒𝑣 ) ⟩ ; 𝑆𝑐𝑢𝑟 ← ⟨𝐿 (𝑛𝑐𝑢𝑟 ), 𝑉 (𝑛𝑐𝑢𝑟 ) ⟩ ; (𝐿𝑝𝑟𝑒𝑣 , 𝑉𝑝𝑟𝑒𝑣 ) ← 𝑆𝑝𝑟𝑒𝑣 ; (𝐿𝑐𝑢𝑟 , 𝑉𝑐𝑢𝑟 ) ← 𝑆𝑐𝑢𝑟 ;

Excluded Retained Proj. —

1,940

—

620

1,320

238

818

502

210

253

249

124

200

110

188

110

1,752

188

110

// Stage progression or validation gain if 𝐿𝑐𝑢𝑟 > 𝐿𝑝𝑟𝑒𝑣 then Accept(𝑛𝑐𝑢𝑟 ); ResetNeutralCounter(); return (Continue, 𝑛𝑐𝑢𝑟 ); if 𝐿𝑐𝑢𝑟 = 𝐿𝑝𝑟𝑒𝑣 ∧ 𝑉𝑐𝑢𝑟 > 𝑉𝑝𝑟𝑒𝑣 then Accept(𝑛𝑐𝑢𝑟 ); ResetNeutralCounter(); return (Continue, 𝑛𝑐𝑢𝑟 ); if 𝐿𝑐𝑢𝑟 = 𝐿𝑝𝑟𝑒𝑣 ∧ 𝑉𝑐𝑢𝑟 = 𝑉𝑝𝑟𝑒𝑣 then IncreaseNeutralCounter(); if NeutralCounter() < 𝜃 then return (Observe, 𝑛𝑐𝑢𝑟 ); // Regression or repeated neutrality. Roll back to a dominating ancestor 𝑛𝑡𝑎𝑟𝑔𝑒𝑡 ← DominatingAncestor( G, 𝑛𝑐𝑢𝑟 ); InitNextRound(𝑛𝑡𝑎𝑟𝑔𝑒𝑡 ); RelocalizeRootCause(); return (Rollback, 𝑛𝑡𝑎𝑟𝑔𝑒𝑡 );

current diagnostic evidence rather than from an error-category label alone. Appendix A links the accepted repairs. Retrieval and Use. Retrieval first reads FAILURE_REGION from commit_changed.txt. When unavailable or empty, it uses a fixed tail slice of the current build log. Positive regular expressions must match and negative expressions must not match. Keywords in matching ERR entries associate relevant GL entries. Fixed priority, deduplication, and tie-breaking rules select at most four ERR/GL entries in total for the Solver prompt. Queries use only permitted failure-state and repair-attempt information. The knowledge base is frozen during evaluation. Repair memory and related caches are reset between cases and independent runs. Repository snapshots, mounts, and tool access exclude reference fixes and post-failure repair history. These controls do not rule out public repairs already present in closed-model pretraining.

4.3

4.4

Hierarchical Stateful Rollback

Unlike ordinary patch generation, fuzzing build repair mutates a live workspace across rounds. An incorrect edit may introduce secondary failures, hide the original error, or cause later attempts to build on a polluted state. HSR addresses this non-monotonic feedback problem by constructing a repair-state graph (RSG), where each node records a validated workspace state and each edge captures the transition caused by a patch attempt. State Representation. Each RSG node stores 𝑆 = ⟨𝐿, 𝑉 ⟩. The stage 𝐿 ∈ {1, . . . , 6} represents six ordered pipeline phases, namely Environment Bootstrap, Dependency Resolution, Instrumented Compilation, Fuzzer Linkage, Artifact Validation, and Runtime Fuzz Execution. These correspond to L1 through L6. Advancement is a provisional search signal. A later failure may be newly introduced or newly exposed, and HSR cannot generally distinguish these causes. The auxiliary score 𝑉 ∈ {0, 1, 2, 3} counts passes among artifact recognition (list_fuzzers), infrastructure compliance (check_build), and runtime stability (run_fuzzer). These checks guide state comparison. Only passing check_build determines reported repair success, so the other checks impose no additional acceptance requirement. Stage advancement is the primary progress signal, with validation changes providing auxiliary constraints. State dominance is defined as 𝑆𝑎 ⪰ 𝑆𝑏 if 𝐿𝑎 > 𝐿𝑏 , or if 𝐿𝑎 = 𝐿𝑏 ∧ 𝑉𝑎 ≥ 𝑉𝑏 . Rollback Decision. Algorithm 1 formalizes the HSR rollback policy, which compares 𝑆𝑐𝑢𝑟 with 𝑆𝑝𝑟𝑒𝑣 after each round to select the starting state for the next iteration. Four outcomes are distinguished. First, stage progression (𝐿𝑐𝑢𝑟 > 𝐿𝑝𝑟𝑒𝑣 ) starts from 𝑛𝑐𝑢𝑟 . Second, a stable stage with improved validation (𝐿𝑐𝑢𝑟 = 𝐿𝑝𝑟𝑒𝑣 ∧ 𝑉𝑐𝑢𝑟 > 𝑉𝑝𝑟𝑒𝑣 ) starts from 𝑛𝑐𝑢𝑟 . Third, a stable stage with no gain (𝐿𝑐𝑢𝑟 = 𝐿𝑝𝑟𝑒𝑣 ∧

Reflection Summary and Memory Curation

Because fuzzing-build repair requires repeated, expensive validation, later decisions must retain solved subproblems and failed strategies. Keeping complete logs and patch histories enlarges context and can obscure relevant evidence [21]. RSMC converts each validated repair attempt into compact semantic memory. Specifically, RSMC compares pre-patch and post-patch validation states to identify resolved symptoms, persistent problems, and priorities for the next round, producing a structured progress assessment inspired by verbal reinforcement [32]. It extracts verbose build logs into per-round summaries that preserve decision-relevant information while removing low-level noise. The curated context retains only extracted memory, reflection results, and patch-level artifacts, maintaining a persistent cross-round view of strategy evolution. This helps the agent avoid failed strategies and focus on the primary unresolved failure.

𝑉𝑐𝑢𝑟 = 𝑉𝑝𝑟𝑒𝑣 ) is observed for one round and triggers rollback on the second consecutive neutral round (𝜃 = 2). Fourth, stage regression, or validation decline at the same stage, rolls back to a dominating ancestor. This stage-first rule matches Algorithm 1. A validation decrease accompanying a stage increase does not override the stagefirst heuristic. Rollback Target Selection. HSR searches upward for the nearest ancestor that dominates the current state under ⪰. If no suitable non-root ancestor exists, it returns to the root workspace. Both repositories are physically restored to the target node’s recorded commit identifiers. The fixed neutral tolerance 𝜃 = 2 allows one unchanged round before rollback. Budget Controls. There is no independent per-node attempt limit. Search is bounded by global retries, internal repair rounds, and project-level timeout. The reported main configuration permits eight rounds and 1.5 hours per case. The exact global retry configuration belongs in the artifact, rather than being inferred as a node-level limit.

4.5

Agentless [33] scans both upstream and OSS-Fuzz trees and generates six patch candidates per case. CompileAgent [14] is adapted to fuzz-build validation with a 40-step budget. SWE-Search [2] searches both repositories through a FuzzBuild action with a 20-round Monte Carlo tree search (MCTS) budget. In the reported model configuration, FuzzMedic, Agentless, and CompileAgent use DeepSeek-V4-Flash. SWE-Search uses DeepSeek-V4-Flash, GPT-5.5 Instant, and Claude Sonnet 4.6 for trajectory discrimination. These native budgets are not equivalent in token, time, interaction, or build-attempt consumption. Success and Costs. A repair succeeds when its patch passes OSS-Fuzz’s check_build in the reconstructed context. Artifact recognition and runtime stability contribute to HSR’s auxiliary score 𝑉 . Token counts and elapsed times are medians over successfully repaired cases, while model-service cost is the mean over those cases. Configuration Selection. We scanned 42 round/time-budget configurations on the 128-case benchmark and selected eight rounds and 1.5 hours per case. The parameter scan and main comparison were executed separately. Independent Repetitions. Each main method and ablation configuration was run independently three times on the fixed evaluation set. For FuzzMedic, the mean repair rate is 48.44%, the sample standard deviation is 1.56 percentage points, and the coefficient of variation is 3.23%. The 95% confidence interval for the mean is [44.56%, 52.32%]. It is calculated from the three run-level rates using Student’s 𝑡 distribution with two degrees of freedom. Knowledge-Base Version. The main experiment and applicable ablations use the frozen strict FGRK version specified in Section 4. It contains 56 entries and excludes evaluation projects and related incidents. The FGRK ablation omits these entries.

Implementation

FuzzMedic is implemented in Python using Google ADK. A sequential preparation workflow initializes the historical environment, validates the failure, localizes candidate causes, and prepares repair context. A loop then coordinates patch generation, application, validation, memory updates, and rollback. Agents communicate through structured prompts and a persistent repair trace. Workspace snapshots associate upstream and OSS-Fuzz revisions with validation outcomes so rollback restores physical repository state as well as semantic context. It uses DeepSeek-V4-Flash [7] as the foundation model for all agents, with the reported seed setting 42. Agents for environment initialization, build execution, rootcause localization, rollback decision, and patch application use neardeterministic decoding settings (temperature = 0.0, top_p = 0.1) to maximize consistency. The RSMC and prompt assembly agents use slightly higher settings (temperature = 0.2, top_p = 0.3) to support reflective reasoning and context synthesis. The loop stops when check_build succeeds, eight repair rounds are exhausted, or the 1.5-hour case budget expires. Passing check_build is the sole reported success criterion. The other checks are reference signals for search and HSR state scoring, not additional acceptance gates. Search has no proof that stage advancement is monotonic correctness progress. Complete validation remains necessary.

5.2

Figure 4 reports 62/128 restored builds (48.44%) for FuzzMedic, 27/128 (21.09%) for CompileAgent, 17/128 (13.28%) for SWE-Search, and 10/128 (7.81%) for Agentless. The gap to the strongest nativebudget baseline is 27.35 percentage points after rounding. Figure 3 shows the repair overlap, including 31 cases repaired by FuzzMedic and missed by all three baselines. 5.2.1 Outcomes by Failure Category. Figure 5 partitions the 128 cases and 62 repairs by category. Each category’s repair rate uses its own case count as the denominator. Compilation and dependency failures account for 112 cases (87.50%), so they dominate the aggregate result. RC5–RC9 contain at most two cases each. Their rates do not support reliable category-level generalization or show that rare failures are easier.

Evaluation

We address four research questions (RQs) on repair effectiveness (RQ1), resource requirements (RQ2), component ablations (RQ3), and model/budget sensitivity (RQ4). Main benchmark results are distinguished from supplementary pilots. Independent repetitions quantify observed run variation.

5.1

Repair Effectiveness (RQ1)

5.2.2 Matched Caps and Additional Comparisons. Table 4 compares the systems using a unified model and matched per-case token/time caps, where M denotes one million tokens. CompileAgent repairs more cases at the lowest cap, while FuzzMedic repairs more at higher caps. Under the 8M-token/90-minute cap, FuzzMedic repairs 59 cases. Build and interaction budgets are not matched. Additional experiments compare FuzzMedic with a bare iterative agent using the same model, validator, and round budget on 64 cases. The bare agent repairs four cases, compared with 35 for FuzzMedic.

Setup and Measurement

Benchmark and Baselines. All 128 cases are counted in the repair-rate denominator. The native-budget comparison uses a shared Docker execution backend and check_build criterion. 7

Total: 62/128 repaired (48.44%) Labels: Fixed/Cases (Rate)

FuzzMedic

Agentless CompileAgent SWE-Search

40/83 (48.19%)

RC1 Compilation 13/29 (44.83%)

RC2 Dependency 2/6 (33.33%)

RC3 Config/build files

31 13

1 2 3

(a) Repair effectiveness

21.09% (27/128)

CompileAgent

1,874,876

145,014 0.0

0.5

13.04

2.5

$0.6521

$0.0177 0.0

Time (min)

Fixed Not fixed 20

100

0.2

0.4

0.6

0.8

Cost (USD)

Figure 4: Repair effectiveness and resource consumption on the 128-case benchmark. Token counts and elapsed times are medians over successful cases; monetary costs are means over successful cases. Table 4: Matched token/time-cap pilot on 128 cases, with unmatched build and interaction budgets. Per-case token/time cap

FuzzMedic

CompileAgent

1M / 15 minutes 4M / 60 minutes 8M / 90 minutes

11 (8.59%) 50 (39.06%) 59 (46.09%)

16 (12.50%) 22 (17.19%) 25 (19.53%)

Resource Requirements (RQ2)

Figure 4 also compares resource requirements. Among successfully repaired cases, FuzzMedic uses a median of 1,874,876 tokens and 22.96 minutes, with a mean model-service cost of $0.3257. CompileAgent uses fewer tokens and less time on its successful cases, whereas FuzzMedic achieves a higher repair rate. The median successful patch modifies one file and five lines. Root-cause localization succeeds in 38.71% of repaired cases, while 50.00% involve rollback. Answer to RQ2. Successful repairs require a median of 1.87 million tokens and 22.96 minutes, with a mean model-service cost of $0.3257. The median patch changes one file and five lines.

$0.0122

SWE-Search Agentless

1/1 (100.00%)

5.3

CompileAgent

5.79

Agentless

2.0

$0.3257

Ours

7.16

SWE-Search

1.5

(d) Monetary cost 22.96

CompileAgent

1.0

Tokens (millions)

1/1 (100.00%)

RC9 Fuzzer regression

Answer to RQ1. FuzzMedic repairs 62 of 128 cases (48.44%), including 31 cases missed by all three baselines. Its repair rate exceeds that of the strongest evaluated baseline, CompileAgent, by 27.35 percentage points.

52,459

Repair rate (%)

Ours

1/1 (100.00%)

RC8 Broken fuzz target

Failure Analysis. Among failed attempts entering the repair loop, 41.8% record root-cause localization and 58.2% lack it. Localization can still leave coupled dependency and integration constraints unresolved. In quiche, edits to an outdated patch introduce malformed hunks before exposing Bazel/FuzzTest incompatibilities. Recurring toolchain and path errors further prevent convergence. These traces reveal failures in translating diagnosis into compatible edits, constructing patches, and grounding repair in clear evidence.

410,947

Agentless

RC7 Command/arguments

Figure 5: Repair outcomes by benchmark-local root cause. Labels show repaired cases, category totals, and repair rates. Small-category rates are descriptive.

Ours

SWE-Search

7.81% (10/128)

Agentless

1/1 (100.00%)

Number of cases

CompileAgent

13.28% (17/128)

SWE-Search

1/2 (50.00%)

RC6 Hardware

(b) Token consumption 48.44% (62/128)

RC5 Download

Figure 3: Overlap of successfully repaired cases among FuzzMedic and the three baselines. Each number counts cases in one exclusive region.

Ours

2/4 (50.00%)

RC4 Missing source

5.4

Component Ablations (RQ3)

Table 5 shows that every component removal reduces repairs and raises successful-case median token use by approximately 1.24– 1.48 times. HSR has the largest effect, reducing repairs from 62 to 42 when removed. Its recovery of earlier workspace states complements RSMC’s retention of repair history, allowing subsequent edits to preserve progress while avoiding repeated unsuccessful strategies. ECRCL and FGRK complement this recovery through evidenceguided localization and reusable build constraints before patch generation. Their removal also lowers repair counts, supporting the value of both diagnostic evidence and domain guidance. Figure 6

On 20 applicable C/C++ compilation failures, CXXCrafter repairs five cases, compared with 12 for FuzzMedic.

Table 6: Foundation-model comparison. Tokens and time are successful-case medians.

FuzzMedic w/o ECRCL w/o RSMC w/o FGRK w/o HSR

1 1

Foundation model Fixed Rate (%)

Tokens

Time (min)

DeepSeek-V4-Flash Claude Sonnet 4.6 GPT-5.5 Instant

1,874,876 1,122,970 1,668,605

22.96 20.07 22.71

62 64 58

48.44 50.00 45.31

25 2 0 2

4 2 0

0.33

0.67

1.0

1.5

2.0

2.5

3.0

Time budget (h)

1 0

Figure 6: Overlap of repaired cases between the full system and the four ablations. Each number counts cases in one exclusive region. The legend’s Few-shot RAG denotes FGRK.

Number of repaired cases

1 0 1

Table 5: Component ablations on the 128-case benchmark. Tokens and time are successful-case medians.

Variant

Fixed Rate (%)

Tokens

Time (min)

FuzzMedic (Full)

48.44

1,874,876

22.96

w/o RSMC w/o HSR w/o ECRCL w/o FGRK

51 42 46 52

39.84 32.81 35.94 40.62

2,448,098 2,777,840 2,328,114 2,444,078

24.13 27.41 23.63 24.67

Max repair rounds

Figure 7: Repaired projects under varying round and time budgets. Counts refer to projects rather than failure cases.

shows 25 cases repaired by all configurations and five repaired only by the full system, illustrating differences in the cases reached by each configuration.

Figure 7 shows project-level repair outcomes across 42 combinations of round limits and time budgets. With eight rounds, increasing the time budget from 1.0 to 1.5 and 2.0 hours raises the number of repaired projects from 59 to 62 and 64, respectively. The highest count is 67 projects with ten rounds and three hours. We select eight rounds and 1.5 hours as the default to balance repair effectiveness and execution time. Increasing the time budget from 1.5 to three hours at eight rounds yields three additional repaired projects, indicating diminishing returns from longer execution.

Answer to RQ3. Removing any component reduces repair effectiveness and increases median token use per successful repair. HSR has the largest observed effect, with its removal reducing repairs from 62 to 42. The other removals yield 46–52 repairs.

Answer to RQ4. Repair rates range from 45.31% to 50.00% across the three evaluated models. The budget sweep shows diminishing returns from longer execution, supporting eight rounds and 1.5 hours as a practical effectiveness–time trade-off on this benchmark.

5.5

6 Real-World Impact 6.1 PR-Experiment Workflow

Model and Budget Sensitivity (RQ4)

Table 6 compares DeepSeek-V4-Flash, Claude Sonnet 4.6 [1], and GPT-5.5 Instant [26] using identical prompts, tools, and budgets. Repair rates span 4.69 percentage points. Claude Sonnet 4.6 achieves the highest repair rate and the lowest successful-case median token use and elapsed time. We also evaluate a locally deployed openweight DeepSeek-V4-Flash-0731 model on 32 cases. It repairs 17 cases (53.12%) using eight A100 graphics processing units (GPUs), each with 80 GB of memory, connected through NVLink. This experiment demonstrates that FuzzMedic can perform build repair with a locally hosted model.

The workflow was submitted as a PR to Google’s oss-fuzz-gen repository and exercised through its PR-experiment mechanism. It covers build-log acquisition, failure-metadata extraction, automated repair with build validation, and production of PR information. Human verification precedes external patch submission. Maintainers review and merge the resulting changes. This experiment does not establish adoption as an unattended production service or inclusion in oss-fuzz-gen’s main branch.

Total: 29 repairs = 10 upstream + 19 OSS-Fuzz Row labels: Upstream / OSS-Fuzz / Total

Repair Criterion. Passing check_build establishes build restoration, rather than preservation of harness coverage or semantic equivalence. HSR’s stage ordering guides search, but later-stage failures can be newly introduced or newly exposed.

3/0/3

RC1 Compilation

2/7/9

RC2 Dependency

3/6/9

RC3 Config/build 0/2/2

RC4 Missing source

0/1/1

RC5 Download

1/1/2

RC7 Command/arguments

Fuzzing and Build Failures. OSS-Fuzz automates sanitizerinstrumented fuzzing [8, 29]. Empirical studies characterize OSS-Fuzz failures [25], build errors at Google [28], compiler errors [39], Travis CI failures [3], and CI adoption [13]. Sharma et al. investigate efficient CI/CD fuzzing [30]. Build-bench studies package building across architectures with executable verification [42]. Build Repair. BuildMedic repairs Maven dependencies [22], HireBuild uses build history [12], and CXXCrafter and CompileAgent automate software building [14, 38]. Agentless and SWESearch provide repository-repair localization and search [2, 33]. FuzzMedic instead coordinates upstream and OSS-Fuzz artifacts with official build validation. Program and Vulnerability Repair. GenProg and GenProgJS use test-based repair [6, 19]. KNOD incorporates domain knowledge [15], Tare uses typing constraints [43], ITER repairs multiple locations iteratively [35], and hybrid repair combines LLM-generated patches with program analysis [20]. Logs In, Patches Out uses sanitizer logs [18], APPATCH uses adaptive prompting [24], and PATCHAGENT integrates localization and patch verification [37]. FuzzMedic repairs the earlier build stage, before a runnable fuzzer and crash input are available. Repair Agents and Evaluation. AutoCodeRover, RepairAgent, and HAFixAgent explore autonomous or history-aware repair [4, 31, 40]. SWE-bench evaluates repository-issue resolution [16], while OSS-Fuzz vulnerability repair starts from security findings [41]. Passerine distinguishes test-passing patches from semantic correctness [27]. Agent Feedback and Analysis. ReAct combines reasoning and actions [34], Reflexion uses verbal feedback [32], and long-context research motivates retaining relevant evidence [21]. FuzzMedic applies these ideas through build-state memory and physical rollback. AutoEmpirical automates empirical fault analysis [36].

Upstream OSS-Fuzz

1/2/3

RC8 Broken fuzz target

Number of merged repairs

Figure 8: The 29 maintainer-merged repairs grouped by root cause and repair location. Row labels give upstream, OSSFuzz, and total counts.

6.2

Maintainer-Merged Repairs

The case register contains 29 merged patches across 28 projects. Of these, 10 patches (34.48%) repair upstream defects and 19 (65.52%) repair OSS-Fuzz integration issues, demonstrating contributions to both project code and fuzzing infrastructure. Repairs are dated November 12, 2025 through September 20, 2026. Appendix A lists the project, dates, failure category, repair location, and supporting links for each patch. Figure 8 summarizes the 29 merged repairs, including three longstanding failures that had remained unresolved for more than one year and two cases that had never built successfully. Source or upstream build defects are reviewed in the upstream repository. Integration changes to Dockerfiles, scripts, or harnesses are reviewed through OSS-Fuzz. OSS-Fuzz-side acceptance is evidence of integration-maintenance utility, while upstream acceptance establishes adoption in the upstream project. The three long-standing failures affect airflow, toml_edit, and mdbook-i18n-helpers, with failure-to-repair intervals of 510, 449, and 470 days, respectively. The two previously unbuilt cases are bc-gh and bazel-rules-fuzzingtest. These repairs restore the build prerequisite for continuous fuzzing in projects affected by persistent or previously unresolved integration failures.

Related Work

Discussion and Threats to Validity

Benchmark Scope. Retaining reproducible failures favors recoverable historical environments and accessible version metadata. The same 128-case benchmark was used for parameter selection and evaluation, which may yield optimistic estimates. Compilation and dependency failures dominate the benchmark, and several other categories contain only one or two cases. Knowledge Separation. The frozen FGRK excludes evaluation projects and related incidents. Runtime access excludes reference patches, and memory is reset between cases and runs. These controls reduce direct leakage, but cannot completely exclude public repairs from closed-model pretraining. Variation and Comparisons. Three complete runs characterize observed run-level variation, with the available uncertainty summary covering the full system. Native search budgets differ across methods, while matched token/time caps leave build and interaction counts unmatched. Resource summaries condition on successful cases and exclude unsuccessful-attempt expenditure.

Conclusion

FuzzMedic repairs OSS-Fuzz builds using localization, knowledge, memory, and rollback. It repairs 62 of 128 cases and yields 29 merged patches across 28 projects. Ablations support all four components, especially HSR. Failed attempts expose coupled constraints and ineffective edits. The PR experiment links log acquisition, validated repair, and PR-information generation.

Data Availability

Appendices A and B provide the 29 merged-patch records and the benchmark and knowledge-base construction audit, respectively.

References

Patching. In 34th USENIX Security Symposium (USENIX Security 25). 4481–4500. https://www.usenix.org/conference/usenixsecurity25/presentation/nong [25] Olivier Nourry, Yutaro Kashiwa, Weiyi Shang, Honglin Shu, and Yasutaka Kamei. 2025. My Fuzzers Won’t Build: An Empirical Study of Fuzzing Build Failures. ACM Transactions on Software Engineering and Methodology 34, 2 (Jan. 2025), 1–30. https://doi.org/10.1145/3688842 [26] OpenAI. 2026. GPT-5.5 Instant. https://openai.com/index/gpt-5-5-instant/ [27] Pat Rondon, Renyao Wei, José Cambronero, Jürgen Cito, Aaron Sun, Siddhant Sanyam, Michele Tufano, and Satish Chandra. 2025. Evaluating Agent-based Program Repair at Google. arXiv:2501.07531 https://arxiv.org/abs/2501.07531v1 [28] H. Seo, C. Sadowski, S. Elbaum, E. Aftandilian, and R. Bowdidge. 2014. Programmers’ Build Errors: A Case Study (at Google). In Proceedings of the 36th International Conference on Software Engineering. 724–734. [29] K. Serebryany. 2017. OSS-Fuzz: Google’s Continuous Fuzzing Service for Open Source Software. https://www.usenix.org/conference/usenixsecurity17/technic al-sessions/presentation/serebryany Conference presentation at the USENIX Security Symposium. [30] A. Sharma, C. Cadar, and J. Metzman. 2024. Effective Fuzzing within CI/CD Pipelines (Registered Report). In Proceedings of the 3rd ACM International Fuzzing Workshop. 52–60. [31] Y. Shi, H. Li, B. Adams, and A. E. Hassan. 2025. HAFixAgent: History-Aware Automated Program Repair Agent. arXiv:2511.01047 https://arxiv.org/abs/2511 .01047v1 Version 1, November 2, 2025. [32] N. Shinn, F. Cassano, A. Gopinath, K. Narasimhan, and S. Yao. 2023. Reflexion: Language Agents with Verbal Reinforcement Learning. In Advances in Neural Information Processing Systems, Vol. 36. 8634–8652. [33] C. S. Xia, Y. Deng, S. Dunn, and L. Zhang. 2024. Agentless: Demystifying LLMbased Software Engineering Agents. https://arxiv.org/abs/2407.01489 [34] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. In International Conference on Learning Representations. https://openreview.net/forum?id=ujr5cXIqJf8 [35] H. Ye and M. Monperrus. 2024. ITER: Iterative Neural Repair for Multi-Location Patches. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering (ICSE). 1–13. [36] Jiongchi Yu, Weipeng Jiang, Xiaoyu Zhang, Qiang Hu, Xiaofei Xie, and Chao Shen. 2025. AutoEmpirical: LLM-Based Automated Research for Empirical Software Fault Analysis. arXiv:2510.04997 https://arxiv.org/abs/2510.04997 [37] Z. Yu, Z. Guo, Y. Wu, J. Yu, M. Xu, D. Mu, Y. Chen, and X. Xing. 2025. PATCHAGENT: A Practical Program Repair Agent Mimicking Human Expertise. In 34th USENIX Security Symposium (USENIX Security 25). 4381–4400. https: //www.usenix.org/conference/usenixsecurity25/presentation/yu-zheng [38] Zhengmin Yu, Yuan Zhang, Ming Wen, Yinan Nie, Wenhui Zhang, and Min Yang. 2025. CXXCrafter: An LLM-Based Agent for Automated C/C++ Open Source Software Building. Proceedings of the ACM on Software Engineering 2, FSE (June 2025), 2618–2640. https://doi.org/10.1145/3729386 [39] C. Zhang, B. Chen, L. Chen, X. Peng, and W. Zhao. 2019. A Large-Scale Empirical Study of Compiler Errors in Continuous Integration. In Proceedings of the 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 176–187. [40] Y. Zhang, H. Ruan, Z. Fan, and A. Roychoudhury. 2024. AutoCodeRover: Autonomous Program Improvement. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1592–1604. [41] Y. Zhang, J. Wang, D. Berzin, M. Mirchev, D. Liu, A. Arya, O. Chang, and A. Roychoudhury. 2024. Fixing Security Vulnerabilities with AI in OSS-Fuzz. https: //arxiv.org/abs/2411.03346 [42] Chenyu Zhao, Shenglin Zhang, Zeshun Huang, Weilin Jin, Yongqian Sun, Dan Pei, Chaoyun Zhang, Qingwei Lin, Chetan Bansal, Saravan Rajmohan, and Minghua Ma. 2026. Can Language Models Go Beyond Coding? Assessing the Capability of Language Models to Build Real-World Systems. arXiv:2511.00780 https: //arxiv.org/abs/2511.00780v2 Version 2, May 8, 2026. [43] Q. Zhu, Z. Sun, W. Zhang, Y. Xiong, and L. Zhang. 2023. Tare: Type-Aware Neural Program Repair. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). 1443–1455. [44] J. Śliwerski, T. Zimmermann, and A. Zeller. 2005. When Do Changes Induce Fixes? ACM SIGSOFT Software Engineering Notes 30, 4 (2005), 1–5.

[1] Anthropic. 2026. Introducing Claude Sonnet 4.6. https://www.anthropic.com/ news/claude-sonnet-4-6 [2] A. Antoniades, A. Örwall, K. Zhang, Y. Xie, A. Goyal, and W. Wang. 2025. SWESearch: Enhancing Software Agents with Monte Carlo Tree Search and Iterative Refinement. In International Conference on Learning Representations. https: //openreview.net/forum?id=G7sIFXugTX [3] M. Beller, G. Gousios, and A. Zaidman. 2017. Oops, My Tests Broke the Build: An Explorative Analysis of Travis CI with GitHub. In 2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR). 356–367. [4] Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. 2025. RepairAgent: An Autonomous, LLM-Based Agent for Program Repair. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE, 2188–2200. [5] Code Intelligence. n.d.. Code Intelligence on GitHub. https://github.com/CodeI ntelligenceTesting Accessed November 3, 2026. [6] V. Csuvik, D. Horváth, M. Lajkó, and L. Vidács. 2025. GenProgJS: A Baseline System for Test-Based Automated Repair of JavaScript Programs. IEEE Transactions on Software Engineering 51, 2 (2025), 325–343. [7] DeepSeek. n.d.. DeepSeek API Documentation. https://api-docs.deepseek.com Accessed November 3, 2026. [8] Google. 2016. OSS-Fuzz: Continuous Fuzzing for Open Source Software. https: //github.com/google/oss-fuzz [9] Google. 2021. ClusterFuzzLite: Continuous Fuzzing for CI/CD. https://google.g ithub.io/clusterfuzzlite/ [10] Google. n.d.. OSS-Fuzz Build Status. https://oss-fuzz-build-logs.storage.googlea pis.com/index.html Accessed November 3, 2026. [11] Google. n.d.. Setting Up a New Project: OSS-Fuzz Documentation. https: //google.github.io/oss- fuzz/getting- started/new-project- guide/ Accessed November 3, 2026. [12] F. Hassan and X. Wang. 2018. HireBuild: An Automatic Approach to HistoryDriven Repair of Build Scripts. In IEEE/ACM International Conference on Software Engineering (ICSE). 1078–1089. [13] M. Hilton, T. Tunnell, K. Huang, D. Marinov, and D. Dig. 2016. Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects. In Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering. 426–437. [14] Li Hu, Guoqiang Chen, Xiuwei Shang, Shaoyin Cheng, Benlong Wu, Gangyang Li, Xu Zhu, Weiming Zhang, and Nenghai Yu. 2025. CompileAgent: Automated RealWorld Repo-Level Compilation with Tool-Integrated LLM-based Agent System. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 2078–2091. https://aclanthology.org/2025.acllong.103/ [15] N. Jiang, T. Lutellier, Y. Lou, L. Tan, D. Goldwasser, and X. Zhang. 2023. KNOD: Domain Knowledge Distilled Tree Decoder for Automated Program Repair. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). 1251–1263. [16] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. In International Conference on Learning Representations. https://proceedings.iclr.c c/paper_files/paper/2024/hash/edac78c3e300629acfe6cbe9ca88fb84-AbstractConference.html [17] Y. Kim, S. Han, A. Y. Khamit, and J. Yi. 2023. Automated Program Repair from Fuzzing Perspective. In Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). 854–866. [18] Y. Kim, S. Shin, H. Kim, and J. Yoon. 2025. Logs In, Patches Out: Automated Vulnerability Repair via Tree-of-Thought LLM Analysis. In 34th USENIX Security Symposium (USENIX Security 25). 4401–4419. https://www.usenix.org/conferenc e/usenixsecurity25/presentation/kim-youngjoon [19] Claire Le Goues, ThanhVu Nguyen, Stephanie Forrest, and Westley Weimer. 2011. GenProg: A Generic Method for Automatic Software Repair. IEEE Transactions on Software Engineering 38, 1 (2011), 54–72. [20] F. Li, J. Jiang, J. Sun, and H. Zhang. 2025. Hybrid Automated Program Repair by Combining Large Language Models and Program Analysis. ACM Transactions on Software Engineering and Methodology 34, 7 (2025), 1–28. https://doi.org/10.114 5/3715004 [21] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang. 2024. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics 12 (2024), 157–173. [22] C. Macho, S. McIntosh, and M. Pinzger. 2018. Automatically Repairing Dependency-Related Build Breakage. In IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). 106–117. [23] Valentin JM Manès, HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J Schwartz, and Maverick Woo. 2019. The Art, Science, and Engineering of Fuzzing: A Survey. IEEE Transactions on Software Engineering 47, 11 (2019), 2312–2331. [24] Y. Nong, H. Yang, L. Cheng, H. Hu, and H. Cai. 2025. APPATCH: Automated Adaptive Prompting Large Language Models for Real-World Software Vulnerability

Merged-Patch Register

Table 7 lists the 29 merged patches across 28 projects, comprising 10 upstream fixes and 19 OSS-Fuzz integration fixes. Types use the benchmark-local RC1–RC9 definitions in Table 8. Dates are source-register dates, not agent runtimes. “None yet” indicates that the project has never built successfully. PR/issue links document review context, while the final column links to the fix/merge evidence. The glaze record supplies a PR event rather than a canonical commit, marked explicitly. Table 7: All 29 maintainer-merged repairs, using this paper’s RC1–RC9 category mapping. Case Project

Failure date Repair date Type Repair location

Fix/merge evidence

1 sigstore

2025-11-05

2025-11-12

RC1 Upstream

d8ab8afb

2 mupdf

2025-11-08

2025-11-19

RC5 OSS-Fuzz (Dockerfile)

5ac272f8

3 neqo

2025-11-03

2025-11-22

RC4 OSS-Fuzz (Dockerfile)

261e9e87

4 croaring

2025-10-29

2025-11-21

RC3 Upstream

d5f84330

5 maven

2025-11-25

2025-12-02

RC2 OSS-Fuzz (Dockerfile)

edbab81b

6 dgraph

2025-12-04

2025-12-12

RC3 OSS-Fuzz (build.sh)

2ddf9dba

7 airflow

2024-07-20

2025-12-12

RC2 OSS-Fuzz (Dockerfile)

966a6625

8 xstream

2025-11-07

2025-12-12

RC3 OSS-Fuzz (build.sh)

88c52400

9 pacemaker

2025-11-27

2025-12-13

RC2 OSS-Fuzz (build.sh)

a07a94be

10 flyway

2025-12-09

2025-12-14

RC2 OSS-Fuzz (build.sh)

ff36f234

11 mysql-server

2025-12-04

2025-12-18

RC2 OSS-Fuzz (Dockerfile)

134af986

12 mosquitto

2025-10-01

2025-12-18

RC3 OSS-Fuzz (Dockerfile)

783f3985

13 airflow

2025-12-18

2025-12-23

RC8 OSS-Fuzz (build.sh)

f4f5e12b

14 pffft

2026-01-05

2026-01-14

RC3 OSS-Fuzz (Dockerfile)

722491e7

15 varnish

2026-01-05

2026-01-14

RC3 OSS-Fuzz (Dockerfile)

24a5c105

16 netcdf

2026-01-05

2026-01-14

RC3 OSS-Fuzz (Dockerfile)

be6d6d7b

17 aptos-core

2026-01-30

2026-05-07

RC1 Upstream

44a6cf44

18 roaring-bitmap

2025-08-22

2026-07-20

RC3 Upstream

e140aee9

19 sigstore-java

2025-11-11

2026-07-21

RC2 OSS-Fuzz (build.sh)

d944b515

20 jimfs

2025-10-28

2026-07-21

RC2 Upstream

7b8bcf81

21 toml_edit

2025-05-01

2026-07-24

RC7 OSS-Fuzz (build.sh)

c3deaec3

22 glaze

2025-12-19

2026-08-03

RC1 Upstream

PR event

23 bc-gh

None yet

2026-08-08

RC7 Upstream

d16fbee9

24 uint256

2026-03-01

2026-08-24

RC8 Upstream

3b6e9cde

25 tomcat

2026-08-12

2026-09-15

RC8 OSS-Fuzz (code)

5aed4560

26 compress

2026-09-04

2026-09-16

RC3 Upstream

de8f55df

27 mdbook-i18n-helpers

2025-06-03

2026-09-16

RC2 OSS-Fuzz (Dockerfile)

1d2405cf

28 libunwind

2026-08-29

2026-09-16

RC4 OSS-Fuzz (build.sh)

70a468cd

29 bazel-rules-fuzzing-test

None yet

2026-09-20

RC2 Upstream

faf15ee0

Table 8: Distribution of 128 failure cases across root-cause categories. Family

Keeping Fuzzers on Duty: Repairing Fuzzing Build Breakages in Continuous Open-Source Fuzzing

Analyze & explore related research in Conceptio

Related documents