Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Archive coverage data alongside corpus archives (from AFL++ fork) #2028

Merged
merged 12 commits into from
Oct 13, 2024

Conversation

addisoncrump
Copy link
Contributor

Supercedes #2020. Moving so we (AFL++ people) can collaborate on this PR.

From the original:

Currently, only corpora are saved in the archive and the summaries of coverage are provided at the end of the experiment. This change simply incorporates the saving of the coverage data snapshots next to the trial corpus snapshots.

@addisoncrump
Copy link
Contributor Author

addisoncrump commented Aug 16, 2024

@DonggeLiu Can we try to do a baseline experiment with this PR again? 🙂 It is fully rebased to the latest changes.

I will integrate the analysis changes once there is a public baseline to point the analysis example at.

@DonggeLiu
Copy link
Contributor

/gcbrun run_experiment.py -a --experiment-config /opt/fuzzbench/service/experiment-config.yaml --experiment-name 2024-08-17-2028-bases-1 --fuzzers afl aflplusplus libafl libfuzzer

@DonggeLiu
Copy link
Contributor

Hi @addisoncrump,I started a test exp above.
Experiment 2024-08-17-2028-bases-1 data and results will be available later at:
The experiment data.
The experiment report.
The experiment report(experimental).

If it works well and you'd like to run a full exp (23 hours), could you please rebase to adopt this change?
I forgot to revert temp changes in a previous PR.

Thanks!

@addisoncrump
Copy link
Contributor Author

Rebased. The experiment looks good, all the coverage samples were archived.

@DonggeLiu
Copy link
Contributor

/gcbrun run_experiment.py -a --experiment-config /opt/fuzzbench/service/experiment-config.yaml --experiment-name 2024-08-19-2028-bases-1 --fuzzers afl aflplusplus libafl libfuzzer

@DonggeLiu
Copy link
Contributor

Experiment 2024-08-19-2028-bases-1 data and results will be available later at:
The experiment data.
The experiment report.
The experiment report(experimental).

@addisoncrump
Copy link
Contributor Author

It seems to still not be hitting the measurer...

@DonggeLiu
Copy link
Contributor

This is a really strange, because 2024-08-19-2028-bases-1 has a list of errors about merging coverage summary:
image

But 2024-08-17-2028-bases-1 did not have any:
image

@DonggeLiu
Copy link
Contributor

DonggeLiu commented Aug 21, 2024

QQ: Is the only thing change between those 2 experiments?
image

BTW, I noticed this runtime crash in libafl. I don't think it could cause the failure, but it might be interesting to you:
https://storage.googleapis.com/fuzzbench-data/index.html?prefix=2024-08-19-2028-bases-1/experiment-folders/libxml2_xml-libafl/trial-3070882/results/

It did not happen in 2024-08-17-2028-bases-1, maybe because that experiment was very short?

A possible theory: libafl saved some input into its corpus during this crash, which caused measurement failure?

@addisoncrump
Copy link
Contributor Author

@tokatoka random libafl crash 🙃

@addisoncrump
Copy link
Contributor Author

I confirmed that the only difference is that commit, yes.

Let's add some more debugging and run a very short run with all the benchmarks, I guess?

@tokatoka
Copy link
Contributor

ohh i see. so this is why my experiment didn't complete either

@tokatoka
Copy link
Contributor

tokatoka commented Aug 21, 2024

A possible theory: libafl saved some input into its corpus during this crash, which caused measurement failure?

but it should not affect other fuzzers such as aflplusplus runs right?

@tokatoka
Copy link
Contributor

tokatoka commented Aug 21, 2024

@tokatoka random libafl crash 🙃

can you reproduce?
i used the same setup on fuzzbench but cannot reproduce

@tokatoka
Copy link
Contributor

I updated. @DonggeLiu
Could you run the same command again to see if it fixes the problem or not?

@DonggeLiu DonggeLiu mentioned this pull request Aug 22, 2024
@DonggeLiu
Copy link
Contributor

/gcbrun run_experiment.py -a --experiment-config /opt/fuzzbench/service/experiment-config.yaml --experiment-name 2024-08-22-2028-bases-1 --fuzzers libafl

@DonggeLiu
Copy link
Contributor

A possible theory: libafl saved some input into its corpus during this crash, which caused measurement failure?

Also running an experiment without libafl to help verify this theory.

@DonggeLiu
Copy link
Contributor

/gcbrun run_experiment.py -a --experiment-config /opt/fuzzbench/service/experiment-config.yaml --experiment-name 2024-08-22-2028-bases-2 --fuzzers afl aflplusplus libfuzzer

@DonggeLiu
Copy link
Contributor

Experiment 2024-08-22-2028-bases-1 data and results will be available later at:
The experiment data.
The experiment report.
The experiment report(experimental).

Experiment 2024-08-22-2028-bases-2 data and results will be available later at:
The experiment data.
The experiment report.
The experiment report(experimental).

@addisoncrump
Copy link
Contributor Author

bases-1 seems to be working fine, but bases-2 is not hitting the measurer still.

@tokatoka
Copy link
Contributor

so it looks like the libafl crash is not the cause of this

@tokatoka
Copy link
Contributor

btw for base-1 it seems all the fuzzers are stuck after 10:45m so it was not a successful run either...

@DonggeLiu
Copy link
Contributor

Ops there were a DB issue yesterday which affected both experiments.
Let me re-run them

@DonggeLiu
Copy link
Contributor

/gcbrun run_experiment.py -a --experiment-config /opt/fuzzbench/service/experiment-config.yaml --experiment-name 2024-08-23-2028-libafl --fuzzers libafl

@DonggeLiu
Copy link
Contributor

/gcbrun run_experiment.py -a --experiment-config /opt/fuzzbench/service/experiment-config.yaml --experiment-name 2024-08-23-2028-bases --fuzzers afl aflplusplus libfuzzer

@tokatoka
Copy link
Contributor

we have experiment-folder but not report. so the measurement is still broken

@tokatoka
Copy link
Contributor

tokatoka commented Aug 23, 2024

For the report:
2024-08-23-2028-libafl and 2024-08-23-2028-bases is missing
but 2024-08-23-2036-bases-1 (from the other PR) is there

For the experiment-data: nothing is missing.

@tokatoka
Copy link
Contributor

Btw if the experiment on my branch and https://www.fuzzbench.com/reports/experimental/2024-08-23-dgfuzz/index.html ← this experiment are working. would it be possible that the changes in this PR caused the measurement failure??

@DonggeLiu
Copy link
Contributor

Experiment 2024-08-23-2028-libafl data and results will be available later at:
The experiment data.
The experiment report.
The experiment report(experimental).

Experiment 2024-08-23-2028-bases data and results will be available later at:
The experiment data.
The experiment report.
The experiment report(experimental).

@DonggeLiu
Copy link
Contributor

DonggeLiu commented Aug 24, 2024

@addisoncrump would this happen to be related to this PR?
image

It could be due to this error:
image

I think the gsutil rm error is at least benign, because @tokatoka shows 2024-08-23-2036-bases-1 can generate a report:

Btw if the experiment on my branch and https://www.fuzzbench.com/reports/experimental/2024-08-23-dgfuzz/index.html ← this experiment are working. would it be possible that the changes in this PR caused the measurement failure??

and it also has gsutil rm error, but not llvm-profdata error:
image
image

There was another build error (discussed in #2038, as shown above), but I am sure that one is benign and unrelated to the missing report in the experiment.

@addisoncrump
Copy link
Contributor Author

I'm really not sure how it could be. I think it will require manual inspection to understand the root cause here. I don't really understand why this would work locally but not in the cloud environment for these reasons, since we should expect the same errors.

Looking at the changeset: I don't see why anything I did would have affected this, especially since we see inconsistent generation of reports. The only thing I can think of that might cause this would be rate limiting with the bucket or similar.

@DonggeLiu
Copy link
Contributor

DonggeLiu commented Aug 25, 2024

Looking at the changeset: I don't see why anything I did would have affected this, especially since we see inconsistent generation of reports. The only thing I can think of that might cause this would be rate limiting with the bucket or similar.

Yep, I did not think of any reason from this PR either. Yet this seems to be the only place that we can reproduce the no report error: I was trying to reproduce the Fuzz target binary not found. error in this PR, but it did not work either.

Could you please cherry-pick commits from #2038, or rebase your PR on it?
Hopefully those commits can help us understand the cause.

Never mind, I created #2039 for this to keep your PR clean.

This is weird: With the same commits, that experiment works.

Let's wait a bit longer and if that experiments proves the error is flaky, we should be able to merge this.
Not sure we can can consistently reproduce it here though, maybe because we run two experiments together?

@DonggeLiu DonggeLiu mentioned this pull request Aug 25, 2024
@addisoncrump
Copy link
Contributor Author

Hey, what remains for this PR? We settled that the flakiness was not associated to this PR, unless I'm mistaken.

@DonggeLiu
Copy link
Contributor

Hey, what remains for this PR? We settled that the flakiness was not associated to this PR, unless I'm mistaken.

You are right, I will merge this.

@DonggeLiu
Copy link
Contributor

/gcbexp skip

@DonggeLiu DonggeLiu merged commit 2920e74 into google:master Oct 13, 2024
58 of 62 checks passed
@addisoncrump
Copy link
Contributor Author

Any chance we could run another baselines experiment with this? Would be good to have this data in the pocket.

@DonggeLiu
Copy link
Contributor

DonggeLiu commented Oct 21, 2024

Any chance we could run another baselines experiment with this? Would be good to have this data in the pocket.

Yep sure!
Running at a new PR as this PR has been merged.

ardier pushed a commit to ardier/fuzzbench that referenced this pull request Nov 25, 2024
…oogle#2028)

Supercedes google#2020. Moving so we (AFL++ people) can collaborate on this
PR.

From the original:

> Currently, only corpora are saved in the archive and the summaries of
coverage are provided at the end of the experiment. This change simply
incorporates the saving of the coverage data snapshots next to the trial
corpus snapshots.

---------

Co-authored-by: Toka <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants