AFLplusplus
OnDiskCorpus actually only evicts the input from memory, not the entire Testcase
From the docs of OnDiskCorpus:
https://github.com/AFLplusplus/LibAFL/blob/2842f95e2aa4e0c665df3c99f1e46a5f4db52fbd/libafl/src/corpus/ondisk.rs#L1-L6
OnDiskCorpus uses CachedOnDiskCorpus under the hood:
https://github.com/AFLplusplus/LibAFL/blob/2842f95e2aa4e0c665df3c99f1e46a5f4db52fbd/libafl/src/corpus/cached.rs#L1
However, both these docs are wrong: CachedOnDiskCorpus only ever evicts the actual input from memory, the rest of the Testcase is kept in memory, including all metadata.
We should either implement what the docs say (not sure about the performance implications though), or at least fix the docs.
(Disclaimer: I'm only about 95% sure.)
Yeah it's how it is. Fixing the docs sounds good, unless you really really want to implement it..
Not right now, no. In the future, this may be helpful.
Btw: there is no great way right now to do corpus minimization on the fly, right? The cmin examples show it after fuzzing, not during fuzzing.
Not sure, but it should be doable with a simple-ish stage I don't know how useful it is though?
I'm currently running a target that has a lot of wait states, so I'm using decently large overcommit values (10 leads to ~30% CPU load), and I'm mainly constrained by memory. And all these clients have to keep an entire corpus, so any entry that can be removed is good for me. Either because it's offloaded or because it's removed because it's a duplicate. That's why I was wondering.
That's somewhat off topic though.
Add more swap? Add an async executor? Stochastically remove random entries from the corpus, assuming the others will likely still have a copy?