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

Replace the Suboptimal fuzz_tree.py Harness With a Better Alternative #1910

Merged

Conversation

DaveLak
Copy link
Contributor

@DaveLak DaveLak commented Apr 29, 2024

As discussed in the initial fuzzing integration PR1, fuzz_tree.py's implementation was not ideal in terms of coverage and its reading/writing to hard-coded paths inside /tmp was problematic as (among other concerns), it causes intermittent crashes on ClusterFuzz2 when multiple workers execute the test at the same time on the same machine.

The changes here replace fuzz_tree.py completely with a completely new fuzz_repo.py fuzz target which:

  • Uses tempfile.TemporaryDirectory() to safely manage tmpdir creation and tear down, including during multi-worker execution runs.
  • Retains the same feature coverage as fuzz_tree.py, but it also adds considerably more from much smaller data inputs and with less memory consumed (and it doesn't even have a seed corpus or target specific dictionary yet.)
  • Can likely be improved further in the future by exercising additional features of Repo to the harness.

Here are some very rough stats to give a very rough idea of the difference:

Metric fuzz_repo.py (my local testing) fuzz_tree.py (most recent successful CF run)
Coverage 789 163
Features 1023 269
Corpus 19 entries / 57 bytes 30 entries / 1872 bytes

Note on License

Because fuzz_tree.py was removed and fuzz_repo.py was not derived from it, the Apache License call outs in the docs were also updated as they only apply to the singe fuzz_config.py file now.

Footnotes

  1. https://github.com/gitpython-developers/GitPython/pull/1901#discussion_r1565001609

  2. https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68355

As discussed in the initial fuzzing integration PR[^1], `fuzz_tree.py`'s
implementation was not ideal in terms of coverage and its reading/writing to
hard-coded paths inside `/tmp` was problematic as (among other concerns), it
causes intermittent crashes on ClusterFuzz[^2] when multiple workers execute
the test at the same time on the same machine.

The changes here replace `fuzz_tree.py` completely with a completely new
`fuzz_repo.py` fuzz target which:

- Uses `tempfile.TemporaryDirectory()` to safely manage tmpdir creation and
  tear down, including during multi-worker execution runs.
- Retains the same feature coverage as `fuzz_tree.py`, but it also adds
  considerably more from much smaller data inputs and with less memory consumed
  (and it doesn't even have a seed corpus or target specific dictionary yet.)
- Can likely be improved further in the future by exercising additional features
  of `Repo` to the harness.

Because `fuzz_tree.py` was removed and `fuzz_repo.py` was not derived from it,
the Apache License call outs in the docs were also updated as they only apply to
the singe `fuzz_config.py` file now.

[^1]: gitpython-developers#1901 (comment)
[^2]: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68355
@DaveLak
Copy link
Contributor Author

DaveLak commented Apr 29, 2024

CC @EliahKagan

@DaveLak
Copy link
Contributor Author

DaveLak commented Apr 29, 2024

and FWIW, if removing fuzz_tree is not desired for any reason, I did test out tempfile.TemporaryDirectory() there and it works well enough to address the primary concerns raised. My fork has the commit with it: DaveLak@3a04959

Copy link
Member

@Byron Byron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a million!

More efficient fuzzing is great!

@Byron Byron merged commit 5f26779 into gitpython-developers:main Apr 29, 2024
26 checks passed
@DaveLak DaveLak deleted the replace-flaky-fuzz-tree-test branch May 15, 2024 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants