improve cargo fuzz compat and bump to newer libAFL version#7
improve cargo fuzz compat and bump to newer libAFL version#7f0rki wants to merge 6 commits intoAFLplusplus:mainfrom
Conversation
* bumped libAFL version, which breaks sancov 8bit inline counters for some reason. => feature-guarded 8bit inline counters and use pcguard instead. * use the same paths for corpus/crashes as cargo fuzz => this should allow mixing `cargo fuzz` and `cargo libafl`. * feature-guard the Tui away and instead use `env_logger` by default.
I used an fuzzer from libafl repo, sancov_8bit itself is working for me there |
| #[cfg(feature = "sancov_8bit")] | ||
| let edges_observer = { | ||
| let edges = unsafe { &mut COUNTERS_MAPS }; | ||
| // TODO: is the call to edges.clone here the reason for breaking sancov_8bit? |
There was a problem hiding this comment.
Yes
After edges.clone(), OwnedMutSlice::RefRaw becomes OwnedMutSliced::Owned.
then it does not have the reference to the original edge counter
There was a problem hiding this comment.
I see. It works, when I construct a new OwnedMutSlice from the raw parts of the previous one. But I still don't understand how the OwnedMutSlice is supposed to be used in this case. Rather move the OwnedMutSlice out of the COUNTER_MAPS and into the edges parameter of the MultiMapObserver?
Why doesn't the MultiMapObserver to receive a reference to the COUNTER_MAPS? Is it important that the number/size of the maps don't change while fuzzing?
instead of cloning the `COUNTER_MAPS` Vec, it is now drained into a new Vec pass to the Observer
2 participants
cargo fuzzandcargo libafl, i.e. use with a shared corpus.env_loggerby default. seemed more reasonable to me. maybe the default should be the other way around. let me know.Any ideas why the sancov 8bit inline counters do not work anymore? it seems no feedback is observed.