wasmtime / PR #12844 Mutator update · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #12844 Mutator update

Wasmtime GitHub notifications bot (Mar 26 2026 at 04:29):

khagankhan requested wasmtime-fuzz-reviewers for a review on PR #12844.

Wasmtime GitHub notifications bot (Mar 26 2026 at 04:29):

khagankhan requested fitzgen for a review on PR #12844.

Wasmtime GitHub notifications bot (Mar 26 2026 at 04:29):

khagankhan opened PR #12844 from khagankhan:mutator-update to bytecodealliance:main:

Refactor gc_ops: set-based type representation and mutator cleanup

Types representation

Changed rec group membership from a field on SubType to sets owned by
each rec group (BTreeMap<RecGroupId, BTreeSet<TypeId>>). Mutations are
now local set operations — move, split, merge, etc. no longer require
scanning all type_defs to find group members. I assume this will make
the mutations easier for subtypes.

Mutator structure

Extracted TypesMutator for all type/rec-group mutations, operating
on Types directly.

Enabled the alloc feature on mutatis and delegate Vec<GcOp>
add/remove/mutate to the library's built-in vec mutator via mutators::vec().

Misc

Use u32::try_from().expect() instead of as usize casts for limit
checks.

Also should fix #12665

cc @fitzgen @eeide

Wasmtime GitHub notifications bot (Mar 26 2026 at 04:29):

khagankhan requested wasmtime-default-reviewers for a review on PR #12844.

Wasmtime GitHub notifications bot (Mar 26 2026 at 04:33):

khagankhan submitted PR review.

Wasmtime GitHub notifications bot (Mar 26 2026 at 04:33):

khagankhan created PR review comment:

I was getting panics on unwraps/expects that made no sense. The precondition seemed OK but the data itself was inconsistent. For example, the rec group's member set would claim a TypeId that did not exist in type_defs or vice versa.

I believe the reason is: libFuzzer sometimes skips our custom mutator and
flips random bits in the serialized bytes directly. This can produce
deserialized state where the two maps disagree. Then when libFuzzer picks
those corrupted bytes for a custom mutation round, our mutator sees the
inconsistent state and the expects/unwraps fire.

Adding types.fixup() seems to fix it after running ~an hour

Wasmtime GitHub notifications bot (Mar 26 2026 at 04:42):

khagankhan commented on PR #12844:

@fitzgen I think #12577 should be made on top this PR. After a potential merge I will close that one and make a new one on top of this with feedbacks being addressed. I guess it would be easier?

Wasmtime GitHub notifications bot (Mar 26 2026 at 04:42):

khagankhan edited a comment on PR #12844:

@fitzgen I think #12577 should be made on top of this PR. After a potential merge I will close that one and make a new one on top of this with feedbacks being addressed. I guess it would be easier?

Wasmtime GitHub notifications bot (Mar 26 2026 at 08:02):

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

Wasmtime GitHub notifications bot (Mar 26 2026 at 08:03):

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

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 (Mar 26 2026 at 16:59):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Mar 26 2026 at 16:59):

fitzgen created PR review comment:

Your diagnosis is correct, but we shouldn't just call fixup willy-nilly. We should instead commit to a discipline of either:

Make mutations robust to receiving "arbitrary" ASTs rather than relying on only the shape of ASTs that can be produced by our mutations (since we know that our fuzzing setup will just randomly mutate the serialized bytes at times).

Call fixup on the whole AST at the start of mutation, rather than doing spot-fixes, so we can rely on the AST being "valid" in all of our mutations across the whole code base.

We have thus far been doing (1), this change moves us towards (2) but in an ad-hoc way. What is nice about (1) is that performance will probably be better, since we won't be doing things like computing SCCs and all that to break cycles, or at minimum a whole pass over the AST. The downside is that we have to write the mutations somewhat defensively, and handle bad type id references and things like that. The pros/cons of (2) are the opposite.

Have you investigated making the mutations more defensive? I would prefer not to abandon performance too eagerly.

Wasmtime GitHub notifications bot (Mar 26 2026 at 17:17):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Mar 26 2026 at 17:17):

fitzgen created PR review comment:

Also I think we probably want to just create a new rec group for these orphan types here. And this should probably happen after trimming excess types. And then later on when we trim excess rec groups, we need to also trim their types as well.

Wasmtime GitHub notifications bot (Mar 26 2026 at 20:50):

khagankhan updated PR #12844.

Wasmtime GitHub notifications bot (Mar 26 2026 at 20:52):

khagankhan submitted PR review.

Wasmtime GitHub notifications bot (Mar 26 2026 at 20:52):

khagankhan created PR review comment:

a small helper for debug in fixup

Wasmtime GitHub notifications bot (Mar 26 2026 at 20:52):

khagankhan submitted PR review.

Wasmtime GitHub notifications bot (Mar 26 2026 at 20:52):

khagankhan created PR review comment:

Based on our discussion I try to "save" some types after trimming and libfuzzer mutations

Wasmtime GitHub notifications bot (Mar 26 2026 at 20:54):

khagankhan submitted PR review.

Wasmtime GitHub notifications bot (Mar 26 2026 at 20:54):

khagankhan created PR review comment:

no panics. If the deserialization results in a corrupted ops, just skip it and it will be later fixed in to_wasm_binary. This fixup is the "mutation". No need to call fixup in mutations now.

Wasmtime GitHub notifications bot (Mar 26 2026 at 20:54):

khagankhan edited PR review comment.

Wasmtime GitHub notifications bot (Mar 26 2026 at 20:55):

khagankhan commented on PR #12844:

Thanks @fitzgen! Ready for the next round of reviews!

Last updated: Apr 13 2026 at 00:25 UTC