Fuzz nightly: fuzz_scheduler_solver OOMs (solve_milp >2GB RSS) on a small bounded task set — new on 2026年08月25日 #439

Surfaced by the issue-hunt health check, not yet tracked.

Measurement

Fuzz (nightly) run 125 (2026年08月25日, main @ 138a693 / v0.42.0) failed. The failure is isolated to one target — fuzz_scheduler_solver — and it is an OOM, not a panic or hang:

Error: Fuzz target exited with exit status: 71
Reproduce with:
 cargo fuzz run --target=x86_64-unknown-linux-gnu fuzz_scheduler_solver \
 fuzz/artifacts/fuzz_scheduler_solver/oom-c9dae275e8e855ad1dd29dcf09051fe27471730f

• The job uploaded a crash artifact (fuzz-artifacts-fuzz_scheduler_solver, artifact ID 9549504175, 270 bytes — the reproducer input is oom-c9dae275...), whereas the two passing targets (fuzz_aadl_parse, fuzz_codegen_roundtrip) skipped that upload step. So a concrete reproducer exists.
• New this run: the two prior nightlies — run 124 (08-24) and run 123 (08-23) — were green across all three targets. main is unchanged since v0.42.0, so this is a newly-explored corpus input rather than a code regression.

Why this looks like a real bug, not a harness artifact

fuzz/fuzz_targets/fuzz_scheduler_solver.rs bounds the input explicitly and small: n_tasks = len.min(8), n_procs = len.min(4), with period/wcet/deadline as u16 and memory_bytes as u32. Its stated contract:

The call must return Ok or Err — it must never panic, and the outer libfuzzer -timeout backstop catches hangs.

That contract covers panics and hangs but not memory. Driving >2GB RSS (libFuzzer's default rss_limit_mb) through spar_solver::milp::solve_milp on a ≤8-task / ≤4-processor set points at an unbounded/blow-up allocation in the MILP path — the search space is tiny by construction, so this is not "the fuzzer fed a huge input."

Traceability the target names: REQ-SOLVER-001, REQ-SOLVER-003, REQ-SOLVER-005.

Triage this needs (not yet done here)

I have not reproduced or minimized the input this run (no nightly cargo-fuzz toolchain to hand), so the two hypotheses are still open:

1. Real defect in solve_milp — an input shape (e.g. period/wcet = 0, a degenerate deadline, or a bind_to that forces a pathological formulation) makes the solver allocate without bound. Fix in the solver.
2. Harness gap — the MILP formulation is legitimately memory-heavy for some in-bounds shape and the target needs an explicit memory/complexity bound (or a tighter -rss_limit_mb matched to the intended budget).

Next step for whoever picks this up: cargo fuzz tmin the oom-c9dae275... artifact to get the minimal task set, then decide (1) vs (2). The reproducer is in the run's artifacts (30-day retention).

Not claimed

That this is a memory-safety issue or exploitable — it is a resource-exhaustion (OOM) finding. Also not claimed that fuzz_scheduler_solver would otherwise be green long-term; only that this specific OOM is new as of 2026年08月25日 and has a saved reproducer.