Phase 6e fuzz budget - #13
Merged
Merged
Conversation
forest_decode and snapshot_decode had been excluded from the campaign for four phases because both reach MemForest::deserialize, which panicked on a bad node-type byte and overflowed the stack on nested input (D33). The fork fix is now pushed, so the pin moves to 8931ab8 and both targets go back in. All five committed crash artifacts replay clean. A smoke run took forest_decode's corpus from 8 inputs to 514 over 10M runs with no crashes, and snapshot_decode's from 100 to 361. Eight inputs after four phases is the measure of how thoroughly the exclusion had blinded the campaign. Throughput differs by 20x between the two -- 48k exec/s against 2.5k -- which is what the next campaign should be budgeted from rather than the clock. The fix walked into its own trap first. fuzz/ sits outside the workspace and so carries a second [patch.crates-io] block; bumping only the workspace pin left the fuzzer on dc368cc, and every artifact still reproduced -- against a bug already fixed. That reads as a falsified fix rather than a stale pin, and the only give-away was the rev in the panic path. tests/pins_agree.rs now fails if the two revs diverge, or if either is abbreviated. Confirmed to fire by reverting one. Coverage floors: utreexo.rs lines 91.5 -> 91.1, the one figure the pin bump moved. Also found that nightly-2026-09-06 installs rustc f248f4038 2026-09-05, which is not the plain `nightly` of that date and does not report the same region counts -- so floors are now the minimum across all three configurations measured, less 0.3, and verified green against each. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…es it fuzz-runs/*.log are tracked, and scripts/fuzz_72h.sh writes them in place. The 2026-08-25 run is what D36's budget conclusions are read off -- notably that bundle_decode was still finding edges at 71.5 h -- so it moves to a dated subdirectory rather than being overwritten by the run that supersedes it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The logs were committed on 14 Sep while `bundle_decode` still had three days to run, so `bundle_decode.log` stopped mid-stream and `driver.log` held only the launch lines. These are the finished versions: the last stat line, the per-target totals, and the driver's saturation analysis that D45 cites. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…inished The seven-target run (2026-09-10 to 09-17) found no crashes in 103 billion executions. Its own saturation analysis says the budget went to the wrong target. `bundle_decode` had 7 days on 8 forks and reached its ceiling in 2.1 hours. `snapshot_decode` had 24 hours on 1 worker and found its last new edge at 18.1 h. The next step was going to be a structured seed generator for the three targets that gained no edges. Measured first instead: `cargo fuzz coverage` shows every reachable region of all three decoders already executes. The uncovered regions are error arms that an earlier bounds check makes unreachable, plus the empty-input path, which libFuzzer runs at startup but the coverage report never replays. A generator would reach nothing new, so it isn't built. D36's "zero edges means re-seed" is corrected in fuzz/README.md. scripts/fuzz_72h.sh: - `snapshot_decode` gets the long slot and 8 forks. The rest get 72 h, the floor the Phase 6 DoD sets, rather than 24 h. - Crash artifacts are counted against a run-start stamp. The last run reported the five August D33 files as `artifacts=2` and `artifacts=3`, which read as new crashes. PLAN.md no longer claims the DoD's fuzzing half covers 7 of 7. Three targets have never had 72 h on their current decoder. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The analysis printed "These need seeds or a structured generator" for any target that gained no edges. D45 found that false for all three such targets: their decoders were fully covered. The message now says both explanations are possible and names the command that distinguishes them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fuzz budget