-
-
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
Corpus Pruning Stage #2315
Corpus Pruning Stage #2315
Conversation
) -> Result<(), Error> { | ||
if (self.closure)(fuzzer, executor, state, manager)? { | ||
manager.on_restart(state).unwrap(); | ||
std::process::exit(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just return from the fuzz loop?
@@ -108,12 +105,6 @@ where | |||
) -> Result<(), Error> { | |||
start_timer!(state); | |||
|
|||
// Here saturating_sub is needed as self.iterations() might be actually smaller than the previous value before reset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think we should leave this in as option: if I create this stage with 1000 iterations, I don't want it to sometimes stop after 50 iterations. It's simply less correct ATM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw this guy is already deleted in #2331
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and in reality if you do in-process fuzzing you do want to stop fuzz this testcase immediately and just discard this testcase.
restarting fuzzers over and over again is a huge loss of time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't know calling saturating_sub would make this more correct.
Imagine, for the first cycle, this self.iteration() returned 1000. so you fuzz it for 1000 times.
and it crashed at first execution. then there're 999 times remaining.
The next time you restart, self.iteration() returned 100. you saturate_sub() then it becomes 0.
I don' think this is more correct
I'll do it in another pr |
"restarting criteria", i.e. when to restart is undone