Wasmtime GitHub notifications bot (Jan 27 2025 at 17:11): Wasmtime GitHub notifications bot (Jan 27 2025 at 17:11):alexcrichton opened PR #10123 from alexcrichton:refactor-fuzzing-reproduction-flags to bytecodealliance:main:
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Jan 27 2025 at 17:11):alexcrichton requested fitzgen for a review on PR #10123.
Wasmtime GitHub notifications bot (Jan 27 2025 at 17:11):alexcrichton requested wasmtime-fuzz-reviewers for a review on PR #10123.
Wasmtime GitHub notifications bot (Jan 27 2025 at 17:11):alexcrichton requested wasmtime-core-reviewers for a review on PR #10123.
Wasmtime GitHub notifications bot (Jan 27 2025 at 17:11):alexcrichton requested wasmtime-default-reviewers for a review on PR #10123.
Wasmtime GitHub notifications bot (Jan 27 2025 at 17:12):alexcrichton updated PR #10123.
Wasmtime GitHub notifications bot (Jan 27 2025 at 17:12):alexcrichton edited PR #10123:
During fuzzing we emit a debug log of configured options to assist with
reproducing fuzz test cases outside of the fuzzing harness. Mapping
options the fuzzer is using though to CLI flags, for example, is a bit
of an art though and not obvious. Just today we've got a fuzz bug and I
couldn't figure out how to reproduce on the CLI and it turns out the
issue was that I was forgetting a flag that was being configured in
response to another flag. I got a bit fed up with constantly trying to
map one to the other, so I've decided to fix things.This commit adds a
Display for CommonOptionsimplementation to the
wasmtime-cli-flagscrate. This is built on the same macro-construction
infrastructure of all our flags making it a relatively low one-time-cost
to implement this. Each option value now implements not only parsing but
printing as well.Next the
wasmtime-fuzzingcrate was updated to create a
CommonOptionsfirst which is then in turn used to create a
wasmtime::Config. This provides a layer to insert a log statement with
to emit all configuration options in a form that can be easily
copy/pasted to the CLI to reproduce.Overall after doing this I was able to quickly reproduce the bug in
question (yay!). The CLI flag logging is pretty verbose right now since
the fuzzing infrastructure sets many settings redundantly to their
defaults, but reducing flags to a minimum is expected to be relatively
easy compared to otherwise trying to extract the options.
Last updated: Feb 28 2025 at 01:30 UTC