Multi machine follow-up

[tokatoka]

idk but this doesn't work with fuzzers/fuzzbench

[tokatoka]

fatal runtime error: failed to initiate panic, error 5 thread '' panicked at src/lib.rs:238:17: Failed to setup the restarter: Error in Serialization: DeserializeBadVarint

[rmalmain]

from which fuzzer exactly you get this error?

[tokatoka]

fuzzers/fuzzbench then make libafl incldue dump_state feature

[rmalmain]

i check

[tokatoka]

fatal runtime error: failed to initiate panic, error 5
^C^Cthread '<unnamed>' panicked at src/lib.rs:170:10:
An error occurred while fuzzing: Serialize("DeserializeBadVarint",    0: libafl_bolts::Error::serialize
             at /home/toka/LibAFL/libafl_bolts/src/lib.rs:329:38
      <libafl_bolts::Error as core::convert::From<postcard::error::Error>>::from
             at /home/toka/LibAFL/libafl_bolts/src/lib.rs:534:9
   1: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
             at /rustc/8fcd4dd08e2ba3e922d917d819ba0be066bdb005/library/core/src/result.rs:1989:27
      libafl_bolts::staterestore::StateRestorer<SP>::restore
             at /home/toka/LibAFL/libafl_bolts/src/staterestore.rs:280:28
      libafl::events::simple::SimpleRestartingEventManager<MT,S,SP>::launch
             at /home/toka/LibAFL/libafl/src/events/simple.rs:553:34
   2: fuzzbench::fuzz
             at /home/toka/LibAFL/fuzzers/fuzzbench/src/lib.rs:229:34
   3: libafl_main
             at /home/toka/LibAFL/fuzzers/fuzzbench/src/lib.rs:169:5
   4: main
             at /home/toka/LibAFL/libafl_targets/src/libfuzzer.c:38:5
   5: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
   6: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:392:3

[tokatoka]

Removing "libafl_bolts/unsafe_stable_anymap" works. What is the reason that you added it here?

[rmalmain]

advice from Dominik above. it should work nonetheless though

[tokatoka]

😅 🤚 but it doesn't

[rmalmain]

maybe it's just a bug of the unsafe_stable_anymap feature, unrelated to dump_state?

[rmalmain]

i confirm it's from the unsafe_stable_anymap feature, i tried with the feature alone without dump_state and it still triggers the same crash. can you have a look @domenukk?

[tokatoka]

what exactly does this feature do?

[rmalmain]

it makes the deseralization work across different compilations of libafl. the problem if TypeId is that it is an arbitrary number that can change from compilation to compilation. type_name is stable as long as the name of the type remains the same.

[tokatoka]

ok then it won't work without this.

[tokatoka]

But I agree, for our experiment this is okay. but for this to be merged, StdStateDump and TestcaseDump is too dirty

[tokatoka]

The only information that we can get now is just the bytes of the Testcase and the timestamp.

at this point I would just name this feature as Testcase dump instead of State dump. then it's a useful feature, because you can still get the corpus without ondisk corpus.

[domenukk]

The only information that we can get now is just the bytes of the Testcase and the timestamp.

at this point I would just name this feature as Testcase dump instead of State dump. then it's a useful feature, because you can still get the corpus without ondisk corpus.

I would take the feature out then. Timestamp and Testcase bytes are already in the ondisk corpus

[domenukk]

Also we have the dump to disk stage which does a better job.

[tokatoka]

Also we have the dump to disk stage which does a better job.

yes. in theory we can just achieve the same thing with ifstage and disk stage

[tokatoka]

then we could still keep that INTERRUPT_FUZZER variable though. maybe it could be useful for something else

[domenukk]

now that unsafe stable anymap works you can get the features back(?)

[domenukk]

You could consider dumping to toml or something more human firendly(?)

[tokatoka]

i think we won't merge this in the end?

[domenukk]

Having a proper state dump (like, a full one) could be good?

[rmalmain]

there are changes there that should be merged IMHO. I'll do a clean version of dump_state, i think it's good to have this around

[tokatoka]

i think dump_state should dump the state in a human-readable format (json or toml) and it does not need to dump the testcase, because we already have a stage for it.

[rmalmain]

i agree of the human-readable format. we still need a form of link between this and the tcs no? for example we can store the hash of tcs in the json stuff per fuzzing core or smth

[tokatoka]

if the purpose is to dump the state, there's more proper way to do it without using signals. i'll keep the really necessary part of this and merge