-
-
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
Allow multiple tuneable mutational stages #1437
Allow multiple tuneable mutational stages #1437
Conversation
This needs a |
I already did that and I just tred |
Diff in /Users/runner/work/LibAFL/LibAFL/libafl/src/stages/tuneable.rs at line 1:
//! A [`crate::stages::MutationalStage`] where the mutator iteration can be tuned at runtime
+use alloc::string::{String, ToString};
use core::{marker::PhantomData, time::Duration};
-use alloc::string::{String, ToString};
use libafl_bolts::{current_time, impl_serdeany, rands::Rand};
use serde::{Deserialize, Serialize}; You may need |
Turns out that I forgot to switch the branch |
libafl/src/stages/tuneable.rs
Outdated
} | ||
|
||
/// Get the set iterations | ||
pub fn iters<S: HasMetadata>(state: &S) -> Result<Option<u64>, Error> { | ||
get_iters(state) | ||
pub fn iters<S: HasNamedMetadata>(&self, state: &S) -> Result<Option<u64>, Error> { |
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.
Maybe have a iters_named
fn then?
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.
@domenukk IMO using named is just fine, this is called once per scheduled input IIRC, so not really an hot path.
@andreafioraldi is there overhead for named vs non named? Assuming this is on the hot path, would it make sense to have extra functions for non-named? |
Yes, named is two hashmap lookups, while non named just one |
libafl/src/stages/tuneable.rs
Outdated
} | ||
|
||
/// Get the set iterations | ||
pub fn iters<S: HasMetadata>(state: &S) -> Result<Option<u64>, Error> { | ||
get_iters(state) | ||
pub fn iters<S: HasNamedMetadata>(&self, state: &S) -> Result<Option<u64>, Error> { |
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.
@domenukk IMO using named is just fine, this is called once per scheduled input IIRC, so not really an hot path.
I still don't like that now users have to use a name, I might prefer a second API of |
Done |
Sweet, thx :) |
I can't see obvious reasons to make
TuneableMutationalStage
a singleton class and it's super inconvenient that every fuzzer can only have oneTuneableMutationalStage
. Therefore, like the observers and feedbacks, I assign a name for eachTuneableMutationalStage
to allow multiple mutational strages while keeping maximum backward compatibility.