Targeted Fuzzing #482

Activity

1. shouc commented on May 25, 2024

   

   shouc

   on May 25, 2024

   Contributor

   More actions

   Sounds interesting and promising! There seems to be no work on distance-based scheduling for stateful ops.

   It would be relatively easy to implement in ItyFuzz as you can directly implement a new power schedule like: https://github.com/fuzzland/ityfuzz/blob/master/src/evm/scheduler.rs#L378-L411

   👍React with 👍1Reacted by plotchy

   👀React with 👀1Reacted by plotchy
2. plotchy commented on May 27, 2024

   

   plotchy

   on May 27, 2024

   ContributorAuthor

   More actions

   @shouc

   At the moment I've been testing through modifying the PowerScheduler's next() fn to only select from testcases that I've chosen as closest.

   I chose to do it this way as you can "prune" the corpus even as it grows. Since corpus is added every time coverage gets better, its gets to be pretty large (like BIGFI_exp.txt hits 300+ in a few mins [32m INFO�[0m [Testcase #0] run time: 0h-1m-30s, clients: 1, corpus: 373, objectives: 0, executions: 269991, exec/sec: 3.015k).

   Since next() always iterates from index 0 to last and loops back to 0, it wastes a lot of time on early indexes that are no longer best.

   Do you think keeping next() as is and modifying compute() to run the close testcases more is better? I can see there being advantages to running old inputs every so often but would be worried about very large corpuses wasting time

   ityfuzz/src/evm/scheduler.rs

   Lines 299 to 313 in abc46e3

   	fn next(&mut self, state: &mut Self::State) -> Result<CorpusId, Error> {
   	if state.corpus().count() == 0 {
   	Err(Error::empty("No entries in corpus".to_owned()))
   	} else {
   	let id = state
   	.corpus()
   	.current()
   	.map(|id| state.corpus().next(id))
   	.flatten()
   	.unwrap_or_else(|| state.corpus().first().unwrap());
   	self.set_current_scheduled(state, Some(id))?;
   	Ok(id)
   	}
   	}
   	}