decode seeds with the matching fuzz-target generator#71
Conversation
seed_to_wasm always decoded seeds with NoTrapsModule, but the `validate` fuzz target generates modules with FuzzModule. The two configure wasm-smith differently (no_traps sets disallow_traps), so they consume input bytes differently and produce different modules from the same seed, reproducing a `validate` crash reconstructed the wrong module. Add a `wasm_from_seed(seed, target)` helper to the fuzzing library and a `--target no_traps|validate` flag to the binary (default no_traps, so existing usage is unchanged). Thread an optional TARGET variable through the Makefile trace/seed-to-wasm targets, and add the missing `--` separator so arguments actually reach the binary. Add tests that the two generators produce different wasm from the same seed and that generation is deterministic.
|
Welcome, new contributor! Please make sure you've read our contributing guide, as well as our policy regarding AI usage, and we look forward to reviewing your pull request shortly |
|
@Kronos3 I added tests for posterity. Maybe this "bug" will not be a bug some time in the future due to changes in Rust, the compiler, or the WA spec itself. Let me know if the tests should stay in the PR in addition to the "fix". |
CoreMark Benchmark ResultsCurrent Score: 261.199 |
Code Coverage ReportCurrent Coverage: 93.64% |
|
Yeah, was thinking about that too , if we go the env var route, running Doing it as a --target flag on the CLI tool with path auto-detection |
|
@Kronos3 I'm a bit confused by the automated benchmark result. My changes in this PR should not have influenced the CoreMark benchmark in any way yet the bot reports an increase in the score. Is it possible that the machines used by Github Runners are different at times and the hardware is faster? I'm also not sure if that benchmark is hardware agnostic and actually measures CPU time instead of wall time. |
2 participants
seed_to_wasmalways decodes seeds withNoTrapsModulebut thevalidatefuzz target usesFuzzModule. The two configure wasm-smith differently (no_trapssetsdisallow_traps), so they consume input bytes differently and produce different modules from the same seed. So reproducing avalidatecrash viamake tracerebuilt a different module than the one that crashed.Fix
wasm_from_seed(seed, target)helper to the fuzzing library and a--target no_traps|validateflag to the binary. Default staysno_traps, so existing usage is unchanged.TARGETvariable through the Makefiletrace/seed-to-wasmtargets, and add the missing--separator so arguments actually reach the binary.Tests
Added tests to prove that the two generators produce different wasm from the same seed and that the generation is deterministic.
Usage
This bug cooked my brain before I figured out why debugging does not work. Hopefullt this will stay fixed for good now.
Closes #47