Skip to content

Fuzzer: Improve handling of small inputs and their debugging#7832

Merged
kripken merged 6 commits into
WebAssembly:mainfrom
kripken:fuzz.less
Aug 15, 2025
Merged

Fuzzer: Improve handling of small inputs and their debugging#7832
kripken merged 6 commits into
WebAssembly:mainfrom
kripken:fuzz.less

Conversation

@kripken
Copy link
Copy Markdown
Member

@kripken kripken commented Aug 15, 2025

Add a new env var to control the fuzzer input size,

BINARYEN_FUZZER_MAX_BYTES

When set, we will truncate the random bytes we receive as
input in translate-to-fuzz. This makes it simple to bisect on the
input, for example.

Also make the fuzzer notice that the input has run out in more
cases, and stop emitting things. This makes small inputs to
the fuzzer smaller in output.

@kripken kripken requested a review from tlively August 15, 2025 17:08
Copy link
Copy Markdown
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be useful to document the env var somewhere, too.

@kripken
Copy link
Copy Markdown
Member Author

kripken commented Aug 15, 2025

Good idea, added to the wiki,

https://github.com/WebAssembly/binaryen/wiki/Fuzzing#advanced-topics

@kripken kripken merged commit f9d4be9 into WebAssembly:main Aug 15, 2025
17 checks passed
@kripken kripken deleted the fuzz.less branch August 15, 2025 18:44
kripken added a commit that referenced this pull request Apr 28, 2026
This was added to simplify our output when the random data is small - it
makes us pick simpler options, which helps a little there - but the
downsides are large, so revert this part.

Specifically, we consume all the random input to generate functions. We
then do a small amount of random usage at the end, things like export
mutation. To handle that, we keep returning random values even after
the random input is consumed (using some xor-ing to try to keep things
random). But if we just return 0 at that point, we are missing out on a
lot of variety.

This was added in #7832. All the rest of that PR makes sense - we can
check for the end of the random data and do simpler things - but we
should not do the simplest possible thing in the generic `upTo` method
which would simplify everything, even things we don't want to.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants