-
-
Notifications
You must be signed in to change notification settings - Fork 324
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
Make harness function take mut ref #1338
Conversation
Tested with a simple InMemoryCorpus that prints every corpus entry that gets added and indeed, it only ever gets 3-byte corpus entries. |
Just for reference, this is also needed for #1009 |
What should happen if an executor mutates the input during a re-run? (i.e. calibration stage) - store the updated version of the testcase or not? |
Hmm, good question. Since we don't specify an executor for each stage, I think I need to change all the places where run_target is happening in all the existing stages that call it (Generalization, Colorization, Calibration, Tracing), as well as a couple wrapper executors where execution happens twice but the second time makes no sense to allow the testcase to be mutated, otherwise there would be some pretty unexpected behavior. I do like the idea of stages being allowed to be implemented in a way such that testcases can be mutated on re-run, but it's a horrible idea to change the existing behavior :P |
for calibration stage it's ok because this
it already clones at every run. but overall, yeah, I think it's better to check if the other stages does not further mutate any previously touched inputs |
I also wonder about differential executors -- I think in that case, since they wrap another executor and the user chooses it, we can safely say "Use two non-mut versions of the executor and you're good" (e.g. |
Sorry for the bumper cars programming I'm still trying to figure out how to run |
What do the |
The |
Why not always take a |
Basically just breaking existing API -- if we change the harness type the existing executors take, all existing harnesses break :( if that's okay with y'all though, it's much cleaner to do that and just call it a breaking change. |
Let's just make it 0.11.0 and break APIs? We're doing that constantly (hence the |
yeah don't worry about breaking apis too much. my other pr about executor changes the executor trait alreadty |
Sounds like a plan, I'll prep that! |
Alrighty I think we're good to go on this one if nobody has a problem with the change! |
again 😩 |
please keep the non_mut version of run_target, and add mut version of |
Makes
Executor
's harness function take a mutable input. This allows harnesses to mutate the input (they don't have to, of course). There are a bunch of reasons this might be desirable, but primarily it allows harnesses that know better about the input format to quickly fix up a corpus (for example, if the harness needs more data, it can extend the input to the length it needs). This can be done with a custom mutator (and still should, for example this won't help much with a target that needs grammar-mutated input), but for simple cases this offers an easy out.This is ostensibly a breaking API change, although only an internal one. Fuzzers with a harness that take a
|buf: &BytesInput|
will still work and all the test cases pass with only a modification to therun_target
function needed when calling it directly, which I don't think is super common.Anyway, open for discussion!
Example:
Output: