Stream: git-wasmtime

Topic: wasmtime / PR #12962 Some fuzzing improvements

Wasmtime GitHub notifications bot (Apr 04 2026 at 18:16):

tschneidereit opened PR #12962 from tschneidereit:fuzzing-improvements to bytecodealliance:main:

Together, these lead to a meaningful uptick in coverage from similarly-length local runs.

In particular,

• the dedicated component_async target gave me 60% coverage of runtime/component/concurrent, where OSS-Fuzz is at around 40%
• the misc improvements make all of the sub-targets covered, whereas currently on OSS-Fuzz, this target is virtually unused because, IIUC, most of the time it aborts immediately.

I honestly don't know how useful the dictionary will be, but we should be able to see by observing behavior of the affected fuzzers.

Wasmtime GitHub notifications bot (Apr 04 2026 at 18:16):

tschneidereit requested fitzgen for a review on PR #12962.

Wasmtime GitHub notifications bot (Apr 04 2026 at 18:16):

tschneidereit requested wasmtime-fuzz-reviewers for a review on PR #12962.

Wasmtime GitHub notifications bot (Apr 04 2026 at 21:50):

github-actions[bot] added the label fuzzing on PR #12962.

Wasmtime GitHub notifications bot (Apr 04 2026 at 21:51):

github-actions[bot] commented on PR #12962:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "fuzzing"

Thus the following users have been cc'd because of the following labels:

• fitzgen: fuzzing

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Apr 06 2026 at 15:45):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Apr 06 2026 at 15:45):

fitzgen created PR review comment:

It may make sense to return Corpus::Reject if run returns an error here, since that is just a test-case-generation error, and exploring all test-case-generation errors instead of the fuzz target itself is not particularly useful.

https://docs.rs/libfuzzer-sys/latest/libfuzzer_sys/enum.Corpus.html

Wasmtime GitHub notifications bot (Apr 06 2026 at 15:45):

fitzgen created PR review comment:

This means that the same fuzz input will execute different sub-fuzzers depending on which are enabled or disabled, which is something that we have tried to avoid in the past so that the corpus remains useful across different runs with different FUZZER=... env vars set.

Could we instead do something more similar to what we did before, but with clamping/moduloing/something the which_fuzzer discriminant?

Wasmtime GitHub notifications bot (Apr 06 2026 at 15:46):

fitzgen commented on PR #12962:

• IIUC, most of the time it aborts immediately

Do you mean that it chooses a bad which_discriminant?

Or literal aborts? That would be suspicious

Last updated: Apr 12 2026 at 23:10 UTC