Multi machine follow-up #2334
Multi machine follow-up #2334
Conversation
|
idk but this doesn't work with fuzzers/fuzzbench |
|
fatal runtime error: failed to initiate panic, error 5 |
|
from which fuzzer exactly you get this error? |
|
fuzzers/fuzzbench |
|
i check |
|
You could consider dumping to toml or something more human firendly(?) |
libafl/src/corpus/testcase.rs
Outdated
| @@ -322,6 +371,8 @@ where | |||
| hit_feedbacks: Vec::new(), | |||
| #[cfg(feature = "track_hit_feedbacks")] | |||
| hit_objectives: Vec::new(), | |||
| #[cfg(feature = "dump_state")] | |||
| timestamp: current_time(), | |||
There was a problem hiding this comment.
Why not current_milliseconds for no_std? Also, do we maybe always want this?
| use libafl_bolts::os::unix_signals::{siginfo_t, ucontext_t, Handler, Signal, CTRL_C_EXIT}; | ||
| use libafl_bolts::os::unix_signals::{siginfo_t, ucontext_t, Handler, Signal}; | ||
| #[cfg(all(unix, feature = "std", not(feature = "dump_state")))] | ||
| use libafl_bolts::os::CTRL_C_EXIT; |
libafl/src/events/mod.rs
Outdated
| @@ -51,6 +53,8 @@ use uuid::Uuid; | |||
|
|
|||
| #[cfg(feature = "introspection")] | |||
| use crate::state::HasClientPerfMonitor; | |||
| #[cfg(all(unix, feature = "dump_state"))] | |||
| use crate::INTERRUPT_FUZZER; | |||
libafl/src/state/mod.rs
Outdated
| type StateDump: Serialize + for<'de> Deserialize<'de>; | ||
|
|
||
| /// Get the dump dir, if there is one. | ||
| fn dump_state_dir(&self) -> Option<&PathBuf>; |
There was a problem hiding this comment.
Shouldn't it be a specific file?
libafl/src/state/mod.rs
Outdated
| #[cfg(all(feature = "std", feature = "dump_state"))] | ||
| #[derive(Serialize, Deserialize, Clone, Debug)] | ||
| #[serde(bound = "I: serde::de::DeserializeOwned")] | ||
| pub struct StdStateDump<I> |
There was a problem hiding this comment.
Yeah... this makes no sense anymore - just write the state to disk using serde_json::to_string oder whatever
libafl/src/state/mod.rs
Outdated
| tcs.push(tc_ref.clone().try_into()?); | ||
| } | ||
|
|
||
| Ok(StdStateDump { |
There was a problem hiding this comment.
Why not the dump the whole state now?
There was a problem hiding this comment.
at this point we are doing this just for our experiment
There was a problem hiding this comment.
but to answer the question,
we wanted to parse this in a standalone tool where modules such as Scheduler does not exist, but this cause a problem because we have to add types to it to compile our tool.
That's why we just select a few members from it and make it into another struct (but again, it's just for the experiment
There was a problem hiding this comment.
You can dump to JSON and remove the keys you don't want
or maybe you can change the deserializer to ignore unsupported types
There was a problem hiding this comment.
yes dumping to json is the best option instead of the serialized bytes of states..
|
i think we won't merge this in the end? |
|
Having a proper state dump (like, a full one) could be good? |
|
there are changes there that should be merged IMHO. |
|
i think dump_state should dump the state in a human-readable format (json or toml) |
|
i agree of the human-readable format. |
|
if the purpose is to dump the state, there's more proper way to do it without using signals. |
No description provided.