Skip to content

Try to avoid fuzz disk fullness #3916

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

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .github/workflows/build.yml
Original file line number Diff line number Diff line change
Expand Up @@ -49,10 +49,12 @@ jobs:
run: |
rustup target add thumbv7m-none-eabi
sudo apt-get -y install gcc-arm-none-eabi
sudo apt-get clean
- name: shellcheck the CI and `contrib` scripts
if: "matrix.platform == 'ubuntu-latest'"
run: |
sudo apt-get -y install shellcheck
sudo apt-get clean
shellcheck ci/*.sh -aP ci
shellcheck contrib/*.sh -aP contrib
- name: Set RUSTFLAGS to deny warnings
Expand Down Expand Up @@ -260,6 +262,7 @@ jobs:
run: |
sudo apt-get update
sudo apt-get -y install build-essential binutils-dev libunwind-dev
sudo apt-get clean
- name: Pin the regex dependency
run: |
cd fuzz && cargo update -p regex --precise "1.9.6" --verbose
Expand Down
5 changes: 3 additions & 2 deletions fuzz/ci-fuzz.sh
Original file line number Diff line number Diff line change
Expand Up @@ -18,13 +18,14 @@ export RUSTFLAGS="--cfg=secp256k1_fuzz --cfg=hashes_fuzz"
mkdir -p hfuzz_workspace/full_stack_target/input
pushd write-seeds
RUSTFLAGS="$RUSTFLAGS --cfg=fuzzing" cargo run ../hfuzz_workspace/full_stack_target/input
cargo clean
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't we really not add a du in here to see what needs cleaning and what doesn't? Also to not unnecessarily increase build times.

And can the disk space in github be increased?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Shouldn't we really not add a du in here to see what needs cleaning and what doesn't? Also to not unnecessarily increase build times.

Huh, we only clean up here and below once were done? So should not have ~any overhead to clean target dirs that you aren't using anymore?

Copy link
Contributor

Choose a reason for hiding this comment

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

I thought it would lead to re-downloads of packages. Not that would matter much even if it was the case with a 4h job...

popd

cargo install --color always --force honggfuzz --no-default-features

# Because we're fuzzing relatively few iterations, the maximum possible
# compiler optimizations aren't necessary, so switch to defaults.
# compiler optimizations aren't necessary, so we turn off LTO
sed -i 's/lto = true//' Cargo.toml
sed -i 's/codegen-units = 1//' Cargo.toml
Copy link
Collaborator

Choose a reason for hiding this comment

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

Removing this is likely to slow the build step down substantially.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removing this is likely to slow the build step down substantially.

Which part do you mean exactly. As mentioned below, lto was never used as it conflicts with codegen-units = 1.

With the sed commands above, we would fallback to defaults in CI, meaning lto = false (see https://doc.rust-lang.org/cargo/reference/profiles.html#dev), and codegen-units = 16. Do we expect the latter to make that much of an impact?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes, the build step takes a minute, and making it single-threaded is unlikely to help :). It may be okay because we can parallelize across binaries, but no reason to slow it down more.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, I guess we'll have the benchmark for comparison in a bit. Let's see how long it will take.

Copy link
Contributor Author

@tnull tnull Jul 9, 2025

Choose a reason for hiding this comment

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

The fuzz job on this branch finished in ~4h 20m. Looking at recent examples of PRs where the CI used to pass, it did so in ~4h 15m. I think 5 min/2% difference is acceptable?

Copy link
Contributor Author

@tnull tnull Jul 9, 2025

Choose a reason for hiding this comment

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

Ah, 4h 13m this time around, so we even have some speedup compared to some recent PRs I looked at. Seems the variance in CI is larger than the impact of the actual change.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Alright, yea, then the cross-binary parallelization dominates. Cool. Its less clear to me if this makes a difference on disk space usage, but it doesn't really matter.


export HFUZZ_BUILD_ARGS="--features honggfuzz_fuzz"

Expand Down
Loading