-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
workaround to uses of arbitrary_loop causing non-determinism #199
Comments
Unfortunately this is a fairly fundamental limitation of |
Thanks, I will have to re-think my approach and consider how to seed the fuzzer more effectively |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am implementing Arbitrary by hand and using it with cargo-fuzz. Ideally, I'd like to allow the fuzzer to control the length but I wanted to experiment with different upper bounds before picking one in the harness. However, I noticed that I could not re-use the corpus given changing the upper bound introduced non-determinism, and I'd like to be able to simply insert/ extend from the corpus instead of starting from scratch. Is there an alternative pattern to support looping being configurable without affecting how the rest of the input is interpreted?
For example, I have something in my harness very similar to https://github.com/bytecodealliance/wasm-tools/blob/main/crates/wasm-smith/src/core.rs#L1070 where I am modifying
u.arbitrary_loop(Some(1), Some(100),
. tou.arbitrary_loop(Some(1), Some(1000),
.The text was updated successfully, but these errors were encountered: