Experiment for AFL++ cloning strategies using different pointer analyses

[pietroborrello]

I'd like to request an experiment to compare different strategies to achieve context sensitivity at compile time using different pointer analyses

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[pietroborrello]

@googlebot I signed it!

[google-cla]

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[google-cla]

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[andreafioraldi]

@googlebot I consent.

[jonathanmetzman]

Hi,
Thanks for this PR.
Unfortunately, we need the cores to run our own experiments until next week, so we can't run this experiment yet. I'll merge this when we have free cores/attention to accept this.

[pietroborrello]

It seems the linker is continuosly killed, problably OOM, that's why the CI is failing on https://github.com/google/fuzzbench/actions/runs/1027102495 for our fuzzers.
If there is a way to detect when running CI, we may set a lower number of clones to avoid filling the (somehow) limited Travis memory. However, some pointer analysis may still require a lot of memory (e.g. 8/16GB, not sure what are the limits in Travis)

[jonathanmetzman]

It seems the linker is continuosly killed, problably OOM, that's why the CI is failing on https://github.com/google/fuzzbench/actions/runs/1027102495 for our fuzzers.
If there is a way to detect when running CI, we may set a lower number of clones to avoid filling the (somehow) limited Travis memory. However, some pointer analysis may still require a lot of memory (e.g. 8/16GB, not sure what are the limits in Travis)

It might be a pain to do this because docker builds try to be reproducible so we'd need to define some dockerfile argument and set it at build time (I don't think this is worth the effort).

I'd rather if you could just build it locally, or we try building these in production and if they fail oh well. Let me know when you want this merged.

[pietroborrello]

It might be a pain to do this because docker builds try to be reproducible so we'd need to define some dockerfile argument and set it at build time (I don't think this is worth the effort).

Yes it makes sense, was just wondering if there was already a way to distinguish, but it does not seem the case

I'd rather if you could just build it locally, or we try building these in production and if they fail oh well. Let me know when you want this merged.

We already tested the bug benchmarks locally and excluded the ones that do not build, so you can merge this. Thank you very much