libextractor

CAMPAIGN.md (26786B)

---

 # Running a libextractor fuzzing campaign
 
 This is the measured answer to two questions: **how should a fixed
 number of core-hours be divided across the targets**, and **how long is
 it still worth running**.  Both answers come from a controlled 12-core
 hour on the 2026-07-29 tree, not from intuition, and both are
 uncomfortable: a flat allocation wastes most of its budget, and the
 productive length of a campaign is far shorter than it looks.
 
 `../../contrib/oss-fuzz/run_campaign.sh` implements the conclusion.
 
 
 ## 1. The measurement
 
 Every target got an **identical** budget, so the curves are comparable
 and the allocation could be derived from the data instead of assumed:
 
     36 jobs x 1200 s / 12 cores = 3 full waves = 3715 s wall, 97% busy
 
 32 of the jobs were the targets; 4 were replicates of `fuzz_unzip`,
 `fuzz_msoffice`, `fuzz_rtf` and `fuzz_datasource` with a different PRNG
 seed and their own corpus, to find out how much of any difference is
 just noise.
 
 The tree carried the twelve fixes from `issues.txt`.  Result:
 
 | | |
 |---|---|
 | wall clock | 3715 s (62 min), 12 cores, 12.0 core-hours |
 | crashes / leaks / OOM / timeouts | **0** — all 36 jobs reported `0/0/0` |
 | artifacts | **0** |
 | corpus | 1727 seed inputs grew to 6045 |
 | replay of the whole result under ASan+UBSan | **0 sanitizer reports** |
 
 The replay pass is not optional and not redundant.  `-fork=1` reads only
 the child's exit status, so a *recovering* UBSan report leaves no
 artifact and nothing in the log — and seven of the twelve fixed defects
 were exactly that.
 
 
 ## 2. Feature counts are noise; edge coverage is not
 
 The four replicate pairs differ only in PRNG seed:
 
 | target | run 1 `ft` | run 2 `ft` | Δ | run 1 `cov` | run 2 `cov` | Δ |
 |---|---|---|---|---|---|---|
 | fuzz_rtf | 6608 | 7201 | **+9.0 %** | 1047 | 1072 | +2.4 % |
 | fuzz_msoffice | 5332 | 5739 | **+7.6 %** | 1083 | 1100 | +1.6 % |
 | fuzz_unzip | 4560 | 4430 | −2.9 % | 805 | 804 | −0.1 % |
 | fuzz_datasource | 3254 | 3244 | −0.3 % | 650 | 650 | 0.0 % |
 
 libFuzzer's `ft` counter includes value-profile entries and is unbounded,
 so it keeps rising after the fuzzer has stopped reaching new code.  Any
 ranking built on it at this scale is fitting noise.  Everything below
 therefore uses **edge coverage** and **llvm-cov region coverage**, both
 of which reproduce to within about 2 %.
 
 
 ## 3. How long a target is worth running
 
 Seconds each target needed to reach a given fraction of the edge
 coverage it ended the 1200 s slice with:
 
 | | median over 32 targets |
 |---|---|
 | 90 % of final | **12 s** |
 | 95 % of final | **34 s** |
 | 99 % of final | **93 s** |
 
 Only **4 of 32** targets were still gaining at t = 1200 s
 (`fuzz_unzip`, `fuzz_rtf`, `fuzz_qt`, `fuzz_msoffice`); twelve had
 converged within nine seconds.
 
 Aggregated over all 32 targets, the discovery rate collapses by a factor
 of **340** across a single twenty-minute slice:
 
 | window | new edges | rate |
 |---|---|---|
 | 0 – 75 s | 2026 | 3039 edges/core-hour |
 | 75 – 150 s | 117 | 175 edges/core-hour |
 | 150 – 300 s | 80 | 60 edges/core-hour |
 | 300 – 600 s | 61 | 23 edges/core-hour |
 | 600 – 1200 s | 48 | **9 edges/core-hour** |
 
 87 % of everything the slice found arrived in its first 75 seconds.  The
 second half of the run — six of the twelve core-hours — produced 2 % of
 the gain.
 
 Cumulative gain fits `G(t) = 1655 · t^0.050`, which extrapolates to:
 
 | per target | total edges | vs the 20-min slice | cost |
 |---|---|---|---|
 | 20 min | 2332 | — | 10.7 core-hours |
 | 1 h | 2488 | +6.7 % | 32 core-hours |
 | 2 h | 2576 | +10.5 % | 64 core-hours |
 | 8 h | 2760 | +18.3 % | 256 core-hours |
 | 24 h | 2915 | +25.0 % | 768 core-hours |
 | 168 h | 3211 | +37.7 % | 5376 core-hours |
 
 Seventy-two times the budget buys a quarter more coverage.  The marginal
 cost per edge roughly doubles with every doubling of runtime: 0.14
 core-hours per edge going from 20 min to 1 h per target, 1.4 at 8 h,
 3.9 at 24 h.
 
 
 ## 4. Where the remaining code actually is
 
 The campaign corpora were replayed through a coverage build.  Including
 `fuzz_ole2`, which was given its own matching 1200 s slice afterwards,
 the union across all targets is **6488 of 7328 library regions, 88.5 %**.
 The 840 that are left are not evenly spread, and not all of them are
 reachable:
 
 | source file | regions | covered | left | best target |
 |---|---|---|---|---|
 | `common/unzip.c` | 674 | 555 | **119** | fuzz_unzip |
 | `plugins/pack.c` | 128 | 39 | 89 → *unreachable* | fuzz_elf |
 | `plugins/ole2_extractor.c` | 799 | 721 | 78 | fuzz_ole2 |
 | `main/extractor_datasource.c` | 545 | 471 | 74 | fuzz_datasource |
 | `plugins/msoffice_extractor.c` | 548 | 475 | 73 | fuzz_msoffice |
 | `plugins/ogg_extractor.c` | 235 | 162 | 73 | fuzz_ogg |
 | `plugins/qt_extractor.c` | 390 | 334 | 56 | fuzz_qt |
 | `plugins/rtf_extractor.c` | 746 | 690 | 56 | fuzz_rtf |
 | `plugins/png_extractor.c` | 315 | 267 | 48 | fuzz_png |
 | `plugins/msoffice_biff.h` | 181 | 140 | 41 | fuzz_ole2 |
 | `plugins/flac_extractor.c` | 130 | 89 | 41 | fuzz_flac |
 | `plugins/mime_extractor.c` | 52 | 24 | 28 | fuzz_mime |
 | everything else | | | ≤ 10 each | |
 
 Four findings matter more than the table:
 
 **`fuzz_ole2` was the highest-yield target in the tree and had never been
 run.**  Its 1200 s slice took `ole2_extractor.c` from 47.6 % to 90.2 %
 — 341 new regions, 1023 regions/core-hour, against 780 for the next best
 (`fuzz_elf`) and 150 for `fuzz_unzip`.  It also covers
 `plugins/msoffice_biff.h` better than `fuzz_msoffice` does (41 uncovered
 against 64).  It was excluded from `contrib/oss-fuzz/build.sh` because
 the plugin needs libgsf's compiler flags rather than just a `-l`, and
 nobody revisited the exclusion; issue 13 was waiting in it, reachable
 from a file already in `src/plugins/testdata/`.  Build it with
 `LE_FUZZ_GSF=1`.  Note that most of what it *reports* belongs to libgsf
 and glib rather than to libextractor — see `issues.txt` — so it earns a
 place in local campaigns but not in the OSS-Fuzz default set.
 
 **`plugins/pack.c`'s 89 uncovered regions are dead code.**  It is a
 general-purpose (un)packer with sixteen format codes.  Its only two
 callers pass fixed format strings — `"4bW16bH"`, `"WWW"`,
 `"hhwwwwwhhhhhh"`, `"wwwwwwwwww"` and their upper-case variants — so no
 input can reach the rest.  `fuzz_applefile` looks like it has 102
 regions of headroom and actually has none; do not fund it.
 
 **`fuzz_zip`, `fuzz_odf` and `fuzz_msoffice` do not meaningfully cover
 `unzip.c`.**  Their corpora were merged with `fuzz_unzip`'s (961 inputs
 total) and replayed: union coverage of `unzip.c` is 83.4 % against
 `fuzz_unzip`'s 82.3 % alone.  Three targets, 743 inputs, seven extra
 regions.  `unzip.c` should be funded through `fuzz_unzip` and nowhere
 else; `zip_extractor.c` itself is already at 100 %.
 
 **What is left in `unzip.c` is the interesting part.**  The uncovered
 regions concentrate in `parse_current_file_coherency_header` (29) and
 `unzip_open_using_ffd` (18) — the central-directory / local-header
 consistency checks, which is precisely where a ZIP reader gets attacked.
 Reaching them needs a better ZIP generator, not a longer run.
 
 
 ## 5. The recommendation
 
 **Balance.** Weight each target by the library regions still uncovered in
 the files it covers better than any other target, excluding the
 unreachable ones, and damp the third-party wrappers (gif, jpeg, tiff,
 flac, ogg, archive, mime) to 35 % — their remaining regions are error
 returns from giflib/libjpeg/libtiff/FLAC/libvorbis/libarchive/libmagic,
 which those projects fuzz themselves.  Give every target a 300 s floor so
 that a regression anywhere still gets caught.  That table is built into
 `run_campaign.sh`.
 
 **Length.** Three tiers, and the top one is smaller than it looks:
 
 | profile | wall clock on 12 cores | core-hours | what it is for |
 |---|---|---|---|
 | `ci` | ~11 min (300 s floor, every target) | 2.8 | every push; recovers ~93 % of the edges a 20-min-per-target run reaches |
 | `nightly` | 2 h | 24 | floor plus the headroom-weighted share |
 | `deep` | 8 h | 96 | weekly; past here each additional 1 % of edge coverage costs >30 core-hours |
 
 No single job is ever given more than the wall clock, however heavy its
 weight: a target handed nine hours inside an eight-hour campaign would
 still be running when everything else had finished.  `run_campaign.sh`
 water-fills instead — share by weight, clamp at the wall clock,
 redistribute the spill, repeat — so `-t 8` really does take eight hours.
 
 Do not run flat campaigns longer than `deep`.  Beyond roughly 100
 core-hours per run the fitted curve says the money is better spent on:
 
 1. **A structure-aware ZIP generator**, for the `unzip.c` coherency
    checks above — 119 regions, and the ones that matter.
 2. **New targets.**  `fuzz_ole2` had 419 uncovered regions and one live
    defect purely because nobody had built it; that is a far better
    return than another 100 core-hours on the 32 targets that were
    already running.  `fuzz_extract` is still absent from the libFuzzer
    set for a good reason (it `dlopen()`s uninstrumented modules), but it
    is worth running under the built-in driver.
 3. **The replay pass after every fix.**  Issue 12 existed only because
    issue 02 fired first on almost every PNG input and masked it; it was
    found by re-running after patching, not by running longer.
 
 The general shape: on this codebase a campaign is a **corpus-building
 and regression exercise**, not a bug-discovery lottery.  Of the twelve
 defects fixed, four were found within 73 seconds and seven more were
 reachable from the seed corpus with *no fuzzing at all* — replaying
 `src/plugins/testdata/` under UBSan finds them.  Exactly one needed
 fuzzing time, and only after another defect was unmasked.
 
 
 ## 6. Reproducing the measurement
 
 ```sh
 # 1. build, out of tree, with gsf so ole2 is included
 rsync -a --exclude=.git /path/to/libextractor/ /tmp/le/libextractor/
 ( cd /tmp/le/libextractor && make distclean )
 SRC=/tmp/le WORK=/tmp/w OUT=/tmp/out SANITIZER=address \
   LE_FUZZ_EXTRA_PLUGINS=1 LE_FUZZ_GSF=1 \
   /tmp/le/libextractor/contrib/oss-fuzz/build.sh
 
 # 2. flat slice, for comparable curves
 contrib/oss-fuzz/run_campaign.sh -b /tmp/out -o /tmp/camp -c 12 -F 1200 -t 0
 
 # 3. coverage build, replay each corpus, diff against the seed corpus
 SRC=/tmp/le WORK=/tmp/wc OUT=/tmp/cov SANITIZER=coverage \
   LE_FUZZ_EXTRA_PLUGINS=1 LE_FUZZ_GSF=1 \
   /tmp/le/libextractor/contrib/oss-fuzz/build.sh
 LLVM_PROFILE_FILE=p.profraw /tmp/cov/fuzz_unzip -runs=0 /tmp/camp/corpus/fuzz_unzip
 llvm-profdata merge -sparse p.profraw -o p.profdata
 llvm-cov report /tmp/cov/fuzz_unzip -instr-profile=p.profdata
 ```
 
 The per-job stats lines libFuzzer prints in fork mode
 (`#N: cov: .. ft: .. corp: .. time: Ns job: M`) are a ready-made time
 series; that is where sections 2 and 3 come from.
 
 
 ## 7. The staged forensic plugins (measured 2026-08-07)
 
 Sixteen plugins — `apk diskimage ebook geotiff gpx heif id3 iso9660 kml
 lnk mbox pecoff plist sqlite tar webp`, about 24 000 lines of
 hand-written parser — were added to the tree with in-tree harnesses in
 `src/fuzz/Makefile.am`, but they were **not** in
 `contrib/oss-fuzz/build.sh` and not in the weight table, so no campaign
 had ever run one.  They are in both now.
 
 ### The run
 
     48 jobs x 1200 s / 16 cores = 3 waves = 3718 s wall, 16 core-hours
 
 The 1200 s slice is deliberately the same one section 1 used, so the
 headroom numbers below are on the same basis as the older ones.  Of the
 48 jobs, 32 were the sixteen new targets run **twice** with different
 PRNG seeds and independent corpora, and 16 were the highest-weight
 legacy targets as a regression check.
 
 | | |
 |---|---|
 | crashes in the sixteen new targets | **0** |
 | crashes elsewhere | 8 artifacts, all `fuzz_ole2`, all one defect (below) |
 | recovering UBSan reports | **1 defect**, `geotiff_extractor.c` |
 | corpus | 170 MB across 48 corpora |
 | union region coverage | 15 607 / 17 380 = **89.8 %** |
 
 ### Two findings
 
 **`geotiff_extractor.c:1669-1670`, float-cast-overflow.**  `emit_image_tags`
 guards `width` and `height` with `isfinite()` and `> 0.0` but with no
 upper bound, then casts both to `unsigned long long`.  A TIFF tag
 carrying 7.0e22 makes that cast undefined.  The two cases immediately
 below it — `bits` and `samples` — already carry the `4096.0 >` bound
 that this one is missing, so the fix is to match them.  Reproduced in
 both replicates, and it is exactly the shape section 1 warns about: a
 *recovering* report, invisible to `-fork=1`, found only by the replay
 pass.
 
 **The eight `fuzz_ole2` artifacts are one defect, and it is libgsf's.**
 All eight have an identical stack: `iconv` reads past the end of the
 buffer `le_input_read` handed it, called from
 `gsf_doc_meta_data_read_from_msole` via `g_convert_with_iconv`.  This is
 the class section 4 already documents for this target.  `issue13` no
 longer reproduces, so nothing regressed.
 
 ### These plugins do not converge like the old ones
 
 This is the result that matters for scheduling, and it contradicts
 section 3 for the new set:
 
 | time to reach | legacy median (32 targets) | staged median (16 targets) |
 |---|---|---|
 | 90 % of final edge coverage | 12 s | 21 s |
 | 95 % | 34 s | 115 s |
 | 99 % | 93 s | **690 s** |
 | still gaining at 1200 s | 4 of 32 | **11 of 16** |
 
 The 300 s floor was derived from targets that are done in 93 s.  It cuts
 these off mid-climb.  **Run with `-F 900` while they are in the set.**
 
 ### Replicate noise is much larger here, so do not over-read the ranking
 
 Section 2 established that edge coverage reproduces to about 2 % on the
 legacy targets.  It does not here.  Same target, same slice, different
 seed:
 
 | target | Δ edge coverage | target | Δ edge coverage |
 |---|---|---|---|
 | fuzz_sqlite | 0.0 % | fuzz_kml | −3.6 % |
 | fuzz_id3 | 0.0 % | fuzz_diskimage | −3.7 % |
 | fuzz_lnk | −0.1 % | fuzz_apk | −5.7 % |
 | fuzz_heif | −0.1 % | fuzz_plist | −6.7 % |
 | fuzz_iso9660 | +0.2 % | fuzz_gpx | −7.4 % |
 | fuzz_webp | +0.3 % | fuzz_mbox | −9.1 % |
 | fuzz_geotiff | +0.7 % | **fuzz_ebook** | **−16.6 %** |
 | fuzz_tar | −0.8 % | fuzz_pecoff | +4.4 % |
 
 The noisy ones are the deep, slow parsers, and they are noisy for the
 same reason they are slow: `fuzz_mbox` managed 487 k executions in its
 slice where `fuzz_sqlite` managed 60.7 M, a factor of 125, so a single
 seed samples far less of the input space.  The weights below therefore
 come from **llvm-cov region coverage of the merged a+b corpus**, not
 from one run's edge count, and a difference of less than about 20 % in
 this table should not be treated as a real ordering.
 
 ### Where the remaining code is
 
 | source file | regions | covered | left | best target |
 |---|---|---|---|---|
 | `diskimage_extractor.c` | 1030 | 753 | **277** | fuzz_diskimage |
 | `apk_extractor.c` | 927 | 824 | 103 | fuzz_apk |
 | `pecoff_extractor.c` | 943 | 842 | 101 | fuzz_pecoff |
 | `tar_extractor.c` | 356 | 257 | 99 | fuzz_tar |
 | `ebook_extractor.c` | 775 | 678 | 97 | fuzz_ebook |
 | `forensics.c` | 263 | 201 | 62 | fuzz_lnk |
 | `kml_extractor.c` | 807 | 751 | 56 | fuzz_kml |
 | `mbox_extractor.c` | 1382 | 1327 | 55 | fuzz_mbox |
 | `gpx_extractor.c` | 881 | 846 | 35 | fuzz_gpx |
 | `geotiff_extractor.c` | 901 | 868 | 33 | fuzz_geotiff |
 | `id3_extractor.c` | 886 | 855 | 31 | fuzz_id3 |
 | `heif_extractor.c` | 713 | 695 | 18 | fuzz_heif |
 | `plist_extractor.c` | 594 | 580 | 14 | fuzz_plist |
 | `iso9660_extractor.c` | 281 | 274 | 7 | fuzz_iso9660 |
 | `webp_extractor.c` | 225 | 220 | 5 | fuzz_webp |
 | `sqlite_extractor.c` | 549 | 548 | 1 | fuzz_sqlite |
 
 Three things follow.
 
 **`fuzz_diskimage` is the new `fuzz_ole2`.**  277 uncovered regions, more
 than any other target in the tree, and 73 % coverage where every other
 staged plugin is near 90 %.  The cause is the corpus, not the runtime:
 the plugin dispatches on four container formats — QCOW2, VHD, VHDX,
 VMDK — and `src/plugins/testdata/` holds exactly one small sample of
 each.  Fund it first, and give it better seeds.
 
 **`forensics.c` is shared by all sixteen and 24 % of it is uncovered.**
 It is attributed to `fuzz_lnk` only because that target happens to cover
 it best; no single target owns it.  62 regions in code every one of
 these plugins calls is worth more attention than its position in the
 table suggests.
 
 **`fuzz_sqlite` and `fuzz_webp` are done.**  One and five regions left
 after 60.7 M and 39.7 M executions.  Give them the floor and nothing
 more.
 
 ### What to spend the next campaign on
 
 1. **Seeds for `fuzz_diskimage`**, and to a lesser extent `fuzz_tar`
    (72 % covered).  Both are corpus-starved rather than time-starved;
    another hour of the same inputs will not find the other 277 regions.
 2. **`-F 900`**, per the convergence table above.
 3. **A structure-aware generator** is still the honest answer for
    `unzip.c` (61 regions left, concentrated in the central-directory
    coherency checks).  Note that `fuzz_apk` and `fuzz_ebook` link
    `unzip.c` but cover it *worse* than `fuzz_unzip` does — 527 and 521
    regions against 607 — so section 4's conclusion stands unchanged:
    fund `unzip.c` through `fuzz_unzip` and nowhere else.
 
 
 ## 8. The tuned 4-hour run (2026-08-07)
 
 The campaign of section 7 was re-run with everything it taught applied:
 the measured weight table, `-F 900` for the slow-converging staged
 plugins, and enriched seeds for the two targets that turned out to be
 corpus-starved.
 
     49 targets / 16 cores / 4 h = 64 core-hours, water-filled
 
 ### Seeds beat runtime, decisively
 
 Section 7 attributed `fuzz_diskimage`'s 277 uncovered regions to a
 corpus holding exactly one sample of each of its four container formats,
 and `fuzz_tar`'s 99 to a single ustar archive.  Generating the missing
 variants — QCOW2 v2/v3 at three cluster sizes, lazy-refcount, zstd and
 backed images, all five VMDK subformats qemu-img will write, VHDX at
 four block/log combinations, fixed and dynamic VHD; and GNU/ustar/pax/
 v7/oldgnu/posix tars plus sparse members and pax extended headers —
 moved coverage *before any fuzzing at all*:
 
 | file | seeds only, before | seeds only, after | 1200 s campaign of §7 |
 |---|---|---|---|
 | `diskimage_extractor.c` | 55.5 % | **66.2 %** | 73.1 % |
 | `tar_extractor.c` | 54.2 % | **80.1 %** | 72.2 % |
 
 The tar figure is the one to remember: eight generated files reach more
 of the parser than a twenty-minute fuzzing slice did.  When a target's
 headroom is concentrated in format variants the corpus does not contain,
 generating them is worth more than any amount of additional runtime.
 
 ### Findings
 
 **`qt_extractor.c`, heap-buffer-overflow — fixed.**  An 80-byte input.
 `getAtomSize` and `getAtomHeaderSize` both document that
 `checkAtomValid` must have run first, because a size field of 1 selects
 the 64-bit `struct LongAtom` and is read sixteen bytes wide rather than
 eight.  `ilstHandler` validates each entry and passes the real end down,
 but `iTunesTagHandler` ignored its `size` parameter and tested only the
 *declared* size (`asize < hdr + 8`) before handing `pos + hdr` to
 `processDataAtom`, which dereferences the child atom immediately.  A
 child declaring the 64-bit escape therefore read eight bytes past what
 had been guaranteed.  The fix restores the documented precondition with
 the same `checkAtomValid` call the sibling handlers already use.
 Reproducer: `corpus/known-findings/fuzz_qt-issue15.bin`.
 
 **`geotiff_extractor.c`, float-cast-overflow — fixed.**  See section 7.
 Reproducer: `corpus/known-findings/fuzz_geotiff-issue14.bin`.
 
 **The ole2 artifacts are a libgsf defect — patch sent to `patches/`.**
 Diagnosed rather than merely classified this time: `msole_prop_read`
 checks a dictionary entry's length against `end - data + 8` where it
 must be `end - data - 8`, and omits `section->char_size`, which is 2 for
 the Unicode property sets.  A crafted document reads up to `2*len + 16`
 bytes past the property-set section.  It is invisible with libgsf's own
 stdio and memory inputs, whose padded buffers absorb it, and becomes a
 hard ASan report only because `le_input_read` in `ole2_extractor.c`
 hands libgsf a tightly sized buffer.  Rebuilding libgsf 1.14.53 with the
 fix takes all twenty artifacts to zero and leaves `test_ole2` and
 `test_msoffice` passing.
 
 Note that `fuzz_qt` ran this campaign against the *unpatched* plugin —
 the defect was found an hour in, and rebuilding mid-run would have
 invalidated the schedule.  Its artifacts are all the one defect.
 
 
 ## 9. Independent runs beat long runs
 
 The four-hour campaign of section 8 gave its six heaviest targets a
 single uninterrupted four-hour slice each, because that is what
 water-filling a weighted budget does.  Replaying the corpora afterwards
 showed that this was the wrong thing to do, and by a wide margin.
 
 Region coverage of each plugin's own source file, same binary, same
 seed corpus, only the shape of the schedule differing:
 
 | target | 2 x 1200 s, corpora unioned | 1 x 14 000 s | best single 1200 s run |
 |---|---|---|---|
 | `fuzz_ebook` | **678** / 775 | 595 | 669 |
 | `fuzz_apk` | **824** / 927 | 792 | 822 |
 
 Forty core-minutes beat four core-hours, and for both targets even *one*
 twenty-minute run beat the four-hour one.
 
 The mechanism is visible in the logs.  `fuzz_ebook`'s four-hour job
 reached 1193 edges at t = 2570 s and never found another one — it then
 spent 82 % of its slice and 195 million further executions standing
 still, while a twenty-minute run from a different PRNG seed reached
 1395.  libFuzzer commits early to a corpus and mutates within it; when
 that corpus is a poor basin there is no mechanism to leave it, and more
 time cannot help.  A second run from a different seed is not more of the
 same work — it is a second sample of a distribution whose spread
 (section 7: up to 16.6 % on these plugins) dwarfs what extra runtime
 buys.
 
 This is not universal.  Measuring how long each target went without a
 new edge before its slice ended:
 
 | still gaining at the end | plateaued early |
 |---|---|
 | `fuzz_rtf` 0 %, `fuzz_apk` 1 %, `fuzz_gpx` 2 %, `fuzz_pecoff` 3 %, `fuzz_msoffice` 4 %, `fuzz_diskimage` 5 %, `fuzz_mbox` 5 % | `fuzz_ogg` 87 %, `fuzz_ebook` 82 %, `fuzz_unzip` 61 %, `fuzz_datasource` 48 %, `fuzz_kml` 48 % |
 
 Note that `fuzz_apk` is in the *left* column and still lost to two short
 runs: a target can keep finding new edges at a slow rate and yet be in a
 worse basin than a fresh run would have found. Time-to-plateau alone
 does not identify which targets to shard.
 
 ### What was changed
 
 `run_campaign.sh` grew `-S SECONDS` (default 1800).  Any target allotted
 more than one shard's worth is now run as several independent jobs of
 that length, each with its own copy of the seed corpus and its own
 `-seed`, and the shard corpora are unioned into `corpus-merged/` at the
 end.  The core-hour budget and the weight table are untouched; only the
 shape changes.  On 16 cores for 4 h that is 148 jobs instead of 49.
 
 The weight table itself was re-derived from the union of every corpus
 both campaigns produced, which is the least seed-dependent basis
 available: union coverage 17559 / 18889 regions, 93.0 %.
 
 ### The standing advice, revised
 
 1. **Shard.** Leave `-S` alone.  It is worth more than any weight in the
    table.
 2. **Seeds before time.** Section 8's tar result and section 9's ebook
    result point the same way: eight generated files beat a twenty-minute
    slice, and a twenty-minute slice beat four hours.  When a target
    looks starved, ask whether the corpus is missing a format variant
    before asking for more core-hours.
 3. **Then weights**, for apportioning what is left.
 
 
 ## 10. Sharding is a cold-start effect
 
 Section 9 concluded that several independent short runs beat one long
 run, and `-S` was added on that basis.  A two-hour, 16-core, 85-job run
 tested whether it still holds once the corpus is no longer small.  It
 does not, and the qualification matters more than the original result.
 
 The run differed from section 8's in two ways: every target started
 from the accumulated corpus of the previous two campaigns rather than
 from the shipped seeds, and the oversized allocations were sharded.  The
 corpus was distilled first (`-merge=1`, 42 707 inputs down to 16 748,
 338 MB to 116 MB, coverage-neutral: `diskimage_extractor.c` 831 to 830
 regions, `gpx_extractor.c` 855 to 855).
 
 Final edge coverage of the shards of one target, against the
 cold-start seed-to-seed spread that motivated sharding in the first
 place:
 
 | target | shards (warm) | spread | cold-start Δ (§7) |
 |---|---|---|---|
 | fuzz_ebook | 1433 1435 1433 1434 | **0.14 %** | −16.6 % |
 | fuzz_mbox | 1833 1833 | 0.00 % | −9.1 % |
 | fuzz_gpx | 1264 1264 | 0.00 % | −7.4 % |
 | fuzz_apk | 1467 1462 1460 1464 | 0.48 % | −5.7 % |
 | fuzz_kml | 1078 1081 | 0.28 % | −3.6 % |
 | fuzz_diskimage | 824 825 | 0.12 % | −3.7 % |
 | fuzz_pecoff | 1284–1288 | 0.31 % | +4.4 % |
 | fuzz_lnk, heif, id3, geotiff | identical | 0.00 % | ~0 % |
 
 From a large corpus the PRNG seed stops mattering: every shard lands in
 the same place to within half a percent, where cold-start replicates
 differed by up to a sixth.  **It is the corpus, not the seed, that
 decides where a run ends up.**  Sharding buys diversity only while the
 corpus is small enough for trajectory to be in play.
 
 That does not make `-S` wrong — it still prevents the section 9
 pathology, where a single long job plateaus and burns hours on nothing
 (`fuzz_ebook` idle for 82 % of a four-hour slice), and it costs nothing.
 But it should be understood as insurance against a bad trajectory, not
 as a way to buy coverage from a mature corpus.
 
 The warm start itself was the larger effect.  `fuzz_ebook` finished at
 1433 edges from every shard, against 1395 for the best cold-start
 twenty-minute run and 1163 for the worst — the corpus removed the
 variance that section 7 spent its whole budget measuring.
 
 ### Diminishing returns, quantified
 
 | campaign | cost | union region coverage |
 |---|---|---|
 | §7 flat measurement | 16 core-hours | 89.8 % |
 | §8 tuned, 4 h | 64 core-hours | 93.0 % |
 | §10 warm + sharded, 2 h | 32 core-hours | **93.1 %** |
 
 Thirty-two core-hours bought 36 regions.  The library is at the point
 this document predicted in section 5: campaigns are now a regression
 exercise, and new coverage has to come from seeds, new targets, or
 structure-aware generators rather than from runtime.
 
 ### Findings
 
 None new.  All 22 artifacts were `fuzz_ole2`, all carrying the
 `g_convert_with_iconv` signature of the libgsf defect in `patches/`, and
 all 22 stop reporting against a patched libgsf.  The replay pass over
 all 85 corpora produced no recovering UndefinedBehaviorSanitizer reports
 and no other sanitizer output.