Experiment for AFL++ cloning strategies using different map sizes #1231
Conversation
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
|
@googlebot I consent. |
|
Hey @jonathanmetzman we are a bit in a hurry for the deadline (this is for a paper), can I ask you to review it ASAP if you have time? |
|
The experiment https://www.fuzzbench.com/reports/experimental/2021-08-23-cloning/index.html is stuck on 15m from something like 2 days, @inferno-chromium do u know what happened? Did we break the infra 😅? |
|
Maybe google/oss-fuzz#6180 has broken something? We were merged just before #1225 that was fixing it |
We'd like to request an experiment to study the impact of the AFL++'s edge map size on context sensitivity achieved with cloning strategies.
As with PR #1202 it is unlikely that this PR will pass the CI since the builds require quite a lot of memory (8-16Gb on average) and Travis seems to provide limited RAM. However, we already tested the bug benchmarks locally and excluded the ones that do not build.
Also, it would be helpful if you could provide some approximate numbers on the RAM available for the VMs used as builders, so as to limit our technique to avoid filling memory during compilation. Especially for bigger binaries that we produce, some may die at linking stage (e.g. wireshark in experiment
2021-07-09-cloning). Similarly, knowing RAM and cache characteristics in the runners would let us tune the map sizes better.