khagankhan opened PR #11290 from khagankhan:integrate-gc-fuzzer to bytecodealliance:main:
- Add integration of
mutatiswit fuzzer- remove
serialize/deserializefor config instead useu64- use
serialize/deserializeforfuzz_mutate
khagankhan requested fitzgen for a review on PR #11290.
khagankhan requested wasmtime-fuzz-reviewers for a review on PR #11290.
khagankhan requested wasmtime-default-reviewers for a review on PR #11290.
fitzgen created PR review comment:
Nitpicks:
- Newline between methods, as elsewhere in the file
- "returns bool" is not very descriptive, the doc comment should describe what the boolean result means.
fitzgen created PR review comment:
postcardhere too:postcard = { workspace = true }
fitzgen submitted PR review:
Looks good, but there are a handful of small things to address before we merge this. Thanks!
fitzgen created PR review comment:
We already have an oracle for fuzzing table ops, which is what this function is ultimately calling. This is really just a small adapter for when we need to use
Arbitraryto generate a config, and it feels out of place here. The only place we need to actually do that is in the fuzz target itself, so lets just inline it into thefuzz_target!invocation infuzz/fuzz_targets/table_ops.rs.
fitzgen created PR review comment:
We should use
postcardinstead ofbincodehere, because we already depend on it in the workspace and don't need to worry about auditing or anything.postcard = { workspace = true }
fitzgen created PR review comment:
Slight simplification:
bincode::decode_from_slice::<(u64, TableOps), _>(data, bincode::config::standard()) .ok() .unwrap_or_default();
khagan-karimov submitted PR review.
khagan-karimov created PR review comment:
Yea makes sense! I guess I just updated the previous function which was in this file
khagan-karimov submitted PR review.
khagan-karimov created PR review comment:
This is nice!
khagan-karimov submitted PR review.
khagan-karimov created PR review comment:
I just wanted it to pass the clippy haha. Thanks!
khagan-karimov commented on PR #11290:
Thanks! Working on them!
github-actions[bot] commented on PR #11290:
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>
khagankhan updated PR #11290.
khagankhan updated PR #11290.
khagankhan updated PR #11290.
khagankhan updated PR #11290.
fitzgen submitted PR review:
Very close!
We should also remove
table_opsfrom themiscfuzz target as part of this PR, as it will be redundant.With the comment below addressed, this should be good to merge.
Thanks!
fitzgen created PR review comment:
We don't want the fuzz target to take structured types directly, as those get generated via
Arbitrary, and we want to do our serialization- and mutation-based thing here.Instead we should do something like this:
fuzz_target!(|data: &[u8]| { let Ok((seed, ops)) = postcard::from_bytes::<(u64, TableOps)>(data) else { return; } // As before: Make an RNG from the seed, fill the buf with random // data, make an `Unstructured`, call `Config::arbitrary_take_rest`, // and finally invoke `oracles::table_ops(config, ops)`. });Aside: once this PR lands, we should probably remove the
Arbitraryimplementation forTableOpsas we won't be using it anymore and removing it will make usage footguns like this one disappear.
khagankhan updated PR #11290.
khagankhan updated PR #11290.
khagankhan updated PR #11290.
khagankhan updated PR #11290.
fitzgen commented on PR #11290:
@khagankhan it looks like the
Cargo.lockis still updating all dependencies. Do you have a tool that is doing that locally?
khagankhan updated PR #11290.
khagankhan commented on PR #11290:
I ran them locally and passed. Let us see!!
khagankhan commented on PR #11290:
@fitzgen Done :check:
fitzgen submitted PR review:
Thanks!
fitzgen merged PR #11290.
alexcrichton commented on PR #11290:
Would it be possible to re-integrate the
table_opsfuzzer back into the main "misc" fuzzer?
fitzgen commented on PR #11290:
Unfortunately, we can't because it is using mutation-based fuzzing via
mutatisnow, not generative-based fuzzing viaarbitrary. I think that's fine though because it is going to be gaining more GC-specific features and will start exploring new code paths now, rather than just the same paths it has been executing for a long time.
alexcrichton commented on PR #11290:
Sounds good to me :+1:
Last updated: Dec 06 2025 at 07:03 UTC