perf(forge): parallelize stateless fuzzing #12713
Conversation
…es that provided in new coverage
…tore the workers id that found the failure
…cally to prevent going over max_runs
…when not in tokio
DaniPopes
force-pushed
the
dani/parallel-fuzz
branch
from
98a05be to
0bffab4
Compare
DaniPopes
force-pushed
the
dani/parallel-fuzz
branch
from
0bffab4 to
9f4f2f6
Compare
|
|
||
| let corpus_entry = CorpusEntry::new_existing(tx_seq.to_vec(), entry.path.clone())?; | ||
| self.in_memory_corpus.push(corpus_entry); | ||
| } |
There was a problem hiding this comment.
Should this rm corpus files that didn't bring new coverage?
| /// Syncs and calibrates the in memory corpus and updates the history_map if new coverage is | ||
| /// found from the corpus findings of other workers. | ||
| #[instrument(skip_all)] | ||
| fn calibrate( |
There was a problem hiding this comment.
From #11769 (comment)
AFL ++ stores a bit map of the history_map (1-byte hitcount -> bool indicating hit) for each input and then uses this bit map to make sure it doesn't eject an entry that is unique (this would mean updating is_favored to mean it contributes a unique bit to the bitmap).
I think here we need to add a minimize step that finds the smallest set of inputs that cover the intersection of all the edges. Really, a worker should replace the in-memory corpus element if we find a smaller sequence or it finds one sequence that is the super set of N sequences. This would apply to both while fuzzing (prior to exporting to master) and also while syncing (master has a smaller seq.)
grandizzy
left a comment
grandizzy
left a comment
There was a problem hiding this comment.
thank you, left some initial thoughts, still going through / test
| }; | ||
| /// Determines the number of workers to run. | ||
| fn num_workers(&self) -> usize { | ||
| rayon::current_num_threads() |
There was a problem hiding this comment.
should we make this a config so we could set number of workers per test? and maybe default to 1 to preserve current behavior?
There was a problem hiding this comment.
I don't like threads to be a configurable value other than CLI -jX. this is an implementation detail and any weird behavior should be tackled in the implementation not with a config that disables it
There was a problem hiding this comment.
for example adding a minimum runs per worker f90ee86
| //! | ||
| //! ## Workflow | ||
| //! | ||
| //! - Each worker maintains its own local corpus with entries stored as JSON files |
There was a problem hiding this comment.
do you see any issue if we implement the workers sync mechanism with an in-memory database / notify channel instead files and dump on disk only the interesting corpus like we do now
Closes #8898.
Continuation of #11769 + #11842. See these PRs for more details.