Try to avoid `fuzz` disk fullness by tnull · Pull Request #3916 · lightningdevkit/rust-lightning

tnull · 2025-07-08T11:20:32Z

No description provided.

ldk-reviews-bot · 2025-07-08T11:20:36Z

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

TheBlueMatt · 2025-07-08T12:10:42Z

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


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

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?

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.

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

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?

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.

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.

joostjager · 2025-07-08T14:50:48Z

 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


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?

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?

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...

.. to hopefully clear up some disk space in the process.

.. which marginally (~2%) increases the runtime while decreasing the disk usage.

TheBlueMatt

Well, it passed, so it works well enough. Just gonna land this as trivial and we can do whatever it takes later to improve things if it breaks again.

tnull · 2025-07-08T11:20:32Z

No description provided.

ldk-reviews-bot · 2025-07-08T11:20:36Z

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

TheBlueMatt · 2025-07-08T12:10:42Z

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


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

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?

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.

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

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?

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.

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.

joostjager · 2025-07-08T14:50:48Z

 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


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?

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?

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...

.. to hopefully clear up some disk space in the process.

.. which marginally (~2%) increases the runtime while decreasing the disk usage.

TheBlueMatt

Well, it passed, so it works well enough. Just gonna land this as trivial and we can do whatever it takes later to improve things if it breaks again.

tnull · 2025-07-08T11:20:32Z

No description provided.

ldk-reviews-bot · 2025-07-08T11:20:36Z

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

TheBlueMatt · 2025-07-08T12:10:42Z

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


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

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?

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.

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

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?

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.

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.

joostjager · 2025-07-08T14:50:48Z

 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


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?

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?

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...

.. to hopefully clear up some disk space in the process.

.. which marginally (~2%) increases the runtime while decreasing the disk usage.

TheBlueMatt

Well, it passed, so it works well enough. Just gonna land this as trivial and we can do whatever it takes later to improve things if it breaks again.

tnull · 2025-07-08T11:20:32Z

No description provided.

ldk-reviews-bot · 2025-07-08T11:20:36Z

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

TheBlueMatt · 2025-07-08T12:10:42Z

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


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

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?

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.

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

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?

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.

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.

joostjager · 2025-07-08T14:50:48Z

 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


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?

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?

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...

.. to hopefully clear up some disk space in the process.

.. which marginally (~2%) increases the runtime while decreasing the disk usage.

TheBlueMatt

Well, it passed, so it works well enough. Just gonna land this as trivial and we can do whatever it takes later to improve things if it breaks again.

tnull · 2025-07-08T11:20:32Z

No description provided.

ldk-reviews-bot · 2025-07-08T11:20:36Z

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

TheBlueMatt · 2025-07-08T12:10:42Z

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


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

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?

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.

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

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?

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.

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.

joostjager · 2025-07-08T14:50:48Z

 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


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?

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?

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...

.. to hopefully clear up some disk space in the process.

.. which marginally (~2%) increases the runtime while decreasing the disk usage.

TheBlueMatt

Well, it passed, so it works well enough. Just gonna land this as trivial and we can do whatever it takes later to improve things if it breaks again.

tnull · 2025-07-08T11:20:32Z

No description provided.

ldk-reviews-bot · 2025-07-08T11:20:36Z

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

TheBlueMatt · 2025-07-08T12:10:42Z

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


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

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?

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.

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

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?

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.

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.

joostjager · 2025-07-08T14:50:48Z

 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


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?

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?

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...

.. to hopefully clear up some disk space in the process.

.. which marginally (~2%) increases the runtime while decreasing the disk usage.

TheBlueMatt

Well, it passed, so it works well enough. Just gonna land this as trivial and we can do whatever it takes later to improve things if it breaks again.

tnull · 2025-07-08T11:20:32Z

No description provided.

ldk-reviews-bot · 2025-07-08T11:20:36Z

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

TheBlueMatt · 2025-07-08T12:10:42Z

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


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

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?

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.

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

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?

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.

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.

joostjager · 2025-07-08T14:50:48Z

 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


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?

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?

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...

.. to hopefully clear up some disk space in the process.

.. which marginally (~2%) increases the runtime while decreasing the disk usage.

TheBlueMatt

Well, it passed, so it works well enough. Just gonna land this as trivial and we can do whatever it takes later to improve things if it breaks again.

tnull · 2025-07-08T11:20:32Z

No description provided.

ldk-reviews-bot · 2025-07-08T11:20:36Z

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

TheBlueMatt · 2025-07-08T12:10:42Z

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


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

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?

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.

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

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?

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.

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.

joostjager · 2025-07-08T14:50:48Z

 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


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?

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?

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...

.. to hopefully clear up some disk space in the process.

.. which marginally (~2%) increases the runtime while decreasing the disk usage.

TheBlueMatt

Well, it passed, so it works well enough. Just gonna land this as trivial and we can do whatever it takes later to improve things if it breaks again.

tnull requested a review from joostjager July 8, 2025 11:21

Clean apt package cache ASAP to safe some disk space
d33a1d1

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 193e1bf to cd91843Compare July 8, 2025 11:28

tnull changed the title ~~Try to avvoid fuzz disk fullness~~Try to avoid fuzz disk fullnessJul 8, 2025

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from cd91843 to 9fe30c8Compare July 8, 2025 11:53

TheBlueMatt reviewed Jul 8, 2025
View reviewed changes

tnull mentioned this pull request Jul 8, 2025
Fix panic when accessing ssl:// Electrum server lightningdevkit/ldk-node#595
Closed

joostjager reviewed Jul 8, 2025
View reviewed changes

tnull added 2 commits July 9, 2025 09:13

Run cargo clean after write-seeds step
f0ec19d
.. to hopefully clear up some disk space in the process.

Keep codegen-units = 1 for CI fuzzing
f6238fc
.. which marginally (~2%) increases the runtime while decreasing the disk usage.

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 9fe30c8 to f6238fcCompare July 9, 2025 07:19

TheBlueMatt approved these changes Jul 9, 2025
View reviewed changes

TheBlueMatt merged commit 42085b9 into lightningdevkit:mainJul 9, 2025

tnull mentioned this pull request Jul 10, 2025
Add script to generate fuzz coverage #3718
Merged

tnull mentioned this pull request Oct 28, 2025
Make fuzz runtime seconds not iterations #4179
Merged

tnull requested a review from joostjager July 8, 2025 11:21

Clean apt package cache ASAP to safe some disk space
d33a1d1

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 193e1bf to cd91843Compare July 8, 2025 11:28

tnull changed the title ~~Try to avvoid fuzz disk fullness~~Try to avoid fuzz disk fullnessJul 8, 2025

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from cd91843 to 9fe30c8Compare July 8, 2025 11:53

TheBlueMatt reviewed Jul 8, 2025
View reviewed changes

tnull mentioned this pull request Jul 8, 2025
Fix panic when accessing ssl:// Electrum server lightningdevkit/ldk-node#595
Closed

joostjager reviewed Jul 8, 2025
View reviewed changes

tnull added 2 commits July 9, 2025 09:13

Run cargo clean after write-seeds step
f0ec19d
.. to hopefully clear up some disk space in the process.

Keep codegen-units = 1 for CI fuzzing
f6238fc
.. which marginally (~2%) increases the runtime while decreasing the disk usage.

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 9fe30c8 to f6238fcCompare July 9, 2025 07:19

TheBlueMatt approved these changes Jul 9, 2025
View reviewed changes

TheBlueMatt merged commit 42085b9 into lightningdevkit:mainJul 9, 2025

tnull mentioned this pull request Jul 10, 2025
Add script to generate fuzz coverage #3718
Merged

tnull mentioned this pull request Oct 28, 2025
Make fuzz runtime seconds not iterations #4179
Merged

tnull requested a review from joostjager July 8, 2025 11:21

Clean apt package cache ASAP to safe some disk space
d33a1d1

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 193e1bf to cd91843Compare July 8, 2025 11:28

tnull changed the title ~~Try to avvoid fuzz disk fullness~~Try to avoid fuzz disk fullnessJul 8, 2025

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from cd91843 to 9fe30c8Compare July 8, 2025 11:53

TheBlueMatt reviewed Jul 8, 2025
View reviewed changes

tnull mentioned this pull request Jul 8, 2025
Fix panic when accessing ssl:// Electrum server lightningdevkit/ldk-node#595
Closed

joostjager reviewed Jul 8, 2025
View reviewed changes

tnull added 2 commits July 9, 2025 09:13

Run cargo clean after write-seeds step
f0ec19d
.. to hopefully clear up some disk space in the process.

Keep codegen-units = 1 for CI fuzzing
f6238fc
.. which marginally (~2%) increases the runtime while decreasing the disk usage.

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 9fe30c8 to f6238fcCompare July 9, 2025 07:19

TheBlueMatt approved these changes Jul 9, 2025
View reviewed changes

TheBlueMatt merged commit 42085b9 into lightningdevkit:mainJul 9, 2025

tnull mentioned this pull request Jul 10, 2025
Add script to generate fuzz coverage #3718
Merged

tnull mentioned this pull request Oct 28, 2025
Make fuzz runtime seconds not iterations #4179
Merged

tnull requested a review from joostjager July 8, 2025 11:21

Clean apt package cache ASAP to safe some disk space
d33a1d1

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 193e1bf to cd91843Compare July 8, 2025 11:28

tnull changed the title ~~Try to avvoid fuzz disk fullness~~Try to avoid fuzz disk fullnessJul 8, 2025

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from cd91843 to 9fe30c8Compare July 8, 2025 11:53

TheBlueMatt reviewed Jul 8, 2025
View reviewed changes

tnull mentioned this pull request Jul 8, 2025
Fix panic when accessing ssl:// Electrum server lightningdevkit/ldk-node#595
Closed

joostjager reviewed Jul 8, 2025
View reviewed changes

tnull added 2 commits July 9, 2025 09:13

Run cargo clean after write-seeds step
f0ec19d
.. to hopefully clear up some disk space in the process.

Keep codegen-units = 1 for CI fuzzing
f6238fc
.. which marginally (~2%) increases the runtime while decreasing the disk usage.

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 9fe30c8 to f6238fcCompare July 9, 2025 07:19

TheBlueMatt approved these changes Jul 9, 2025
View reviewed changes

TheBlueMatt merged commit 42085b9 into lightningdevkit:mainJul 9, 2025

tnull mentioned this pull request Jul 10, 2025
Add script to generate fuzz coverage #3718
Merged

tnull mentioned this pull request Oct 28, 2025
Make fuzz runtime seconds not iterations #4179
Merged

tnull requested a review from joostjager July 8, 2025 11:21

Clean apt package cache ASAP to safe some disk space
d33a1d1

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 193e1bf to cd91843Compare July 8, 2025 11:28

tnull changed the title ~~Try to avvoid fuzz disk fullness~~Try to avoid fuzz disk fullnessJul 8, 2025

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from cd91843 to 9fe30c8Compare July 8, 2025 11:53

TheBlueMatt reviewed Jul 8, 2025
View reviewed changes

tnull mentioned this pull request Jul 8, 2025
Fix panic when accessing ssl:// Electrum server lightningdevkit/ldk-node#595
Closed

joostjager reviewed Jul 8, 2025
View reviewed changes

tnull added 2 commits July 9, 2025 09:13

Run cargo clean after write-seeds step
f0ec19d
.. to hopefully clear up some disk space in the process.

Keep codegen-units = 1 for CI fuzzing
f6238fc
.. which marginally (~2%) increases the runtime while decreasing the disk usage.

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 9fe30c8 to f6238fcCompare July 9, 2025 07:19

TheBlueMatt approved these changes Jul 9, 2025
View reviewed changes

TheBlueMatt merged commit 42085b9 into lightningdevkit:mainJul 9, 2025

tnull mentioned this pull request Jul 10, 2025
Add script to generate fuzz coverage #3718
Merged

tnull mentioned this pull request Oct 28, 2025
Make fuzz runtime seconds not iterations #4179
Merged

tnull requested a review from joostjager July 8, 2025 11:21

Clean apt package cache ASAP to safe some disk space
d33a1d1

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 193e1bf to cd91843Compare July 8, 2025 11:28

tnull changed the title ~~Try to avvoid fuzz disk fullness~~Try to avoid fuzz disk fullnessJul 8, 2025

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from cd91843 to 9fe30c8Compare July 8, 2025 11:53

TheBlueMatt reviewed Jul 8, 2025
View reviewed changes

tnull mentioned this pull request Jul 8, 2025
Fix panic when accessing ssl:// Electrum server lightningdevkit/ldk-node#595
Closed

joostjager reviewed Jul 8, 2025
View reviewed changes

tnull added 2 commits July 9, 2025 09:13

Run cargo clean after write-seeds step
f0ec19d
.. to hopefully clear up some disk space in the process.

Keep codegen-units = 1 for CI fuzzing
f6238fc
.. which marginally (~2%) increases the runtime while decreasing the disk usage.

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 9fe30c8 to f6238fcCompare July 9, 2025 07:19

TheBlueMatt approved these changes Jul 9, 2025
View reviewed changes

TheBlueMatt merged commit 42085b9 into lightningdevkit:mainJul 9, 2025

tnull mentioned this pull request Jul 10, 2025
Add script to generate fuzz coverage #3718
Merged

tnull mentioned this pull request Oct 28, 2025
Make fuzz runtime seconds not iterations #4179
Merged

tnull requested a review from joostjager July 8, 2025 11:21

Clean apt package cache ASAP to safe some disk space
d33a1d1

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 193e1bf to cd91843Compare July 8, 2025 11:28

tnull changed the title ~~Try to avvoid fuzz disk fullness~~Try to avoid fuzz disk fullnessJul 8, 2025

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from cd91843 to 9fe30c8Compare July 8, 2025 11:53

TheBlueMatt reviewed Jul 8, 2025
View reviewed changes

tnull mentioned this pull request Jul 8, 2025
Fix panic when accessing ssl:// Electrum server lightningdevkit/ldk-node#595
Closed

joostjager reviewed Jul 8, 2025
View reviewed changes

tnull added 2 commits July 9, 2025 09:13

Run cargo clean after write-seeds step
f0ec19d
.. to hopefully clear up some disk space in the process.

Keep codegen-units = 1 for CI fuzzing
f6238fc
.. which marginally (~2%) increases the runtime while decreasing the disk usage.

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 9fe30c8 to f6238fcCompare July 9, 2025 07:19

TheBlueMatt approved these changes Jul 9, 2025
View reviewed changes

TheBlueMatt merged commit 42085b9 into lightningdevkit:mainJul 9, 2025

tnull mentioned this pull request Jul 10, 2025
Add script to generate fuzz coverage #3718
Merged

tnull mentioned this pull request Oct 28, 2025
Make fuzz runtime seconds not iterations #4179
Merged

tnull requested a review from joostjager July 8, 2025 11:21

Clean apt package cache ASAP to safe some disk space
d33a1d1

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 193e1bf to cd91843Compare July 8, 2025 11:28

tnull changed the title ~~Try to avvoid fuzz disk fullness~~Try to avoid fuzz disk fullnessJul 8, 2025

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from cd91843 to 9fe30c8Compare July 8, 2025 11:53

TheBlueMatt reviewed Jul 8, 2025
View reviewed changes

tnull mentioned this pull request Jul 8, 2025
Fix panic when accessing ssl:// Electrum server lightningdevkit/ldk-node#595
Closed

joostjager reviewed Jul 8, 2025
View reviewed changes

tnull added 2 commits July 9, 2025 09:13

Run cargo clean after write-seeds step
f0ec19d
.. to hopefully clear up some disk space in the process.

Keep codegen-units = 1 for CI fuzzing
f6238fc
.. which marginally (~2%) increases the runtime while decreasing the disk usage.

tnull force-pushed the 2025-07-avoid-fuzz-disk-fullness branch from 9fe30c8 to f6238fcCompare July 9, 2025 07:19

TheBlueMatt approved these changes Jul 9, 2025
View reviewed changes

TheBlueMatt merged commit 42085b9 into lightningdevkit:mainJul 9, 2025

tnull mentioned this pull request Jul 10, 2025
Add script to generate fuzz coverage #3718
Merged

tnull mentioned this pull request Oct 28, 2025
Make fuzz runtime seconds not iterations #4179
Merged

Uh oh!

Conversation

tnull commented Jul 8, 2025

Uh oh!

ldk-reviews-bot commented Jul 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnullJul 9, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnullJul 9, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

tnull commented Jul 8, 2025

Uh oh!

ldk-reviews-bot commented Jul 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnullJul 9, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnullJul 9, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

ldk-reviews-bot commented Jul 8, 2025•
edited
Loading

tnullJul 9, 2025•
edited
Loading

tnullJul 9, 2025•
edited
Loading

ldk-reviews-bot commented Jul 8, 2025•
edited
Loading

tnullJul 9, 2025•
edited
Loading

tnullJul 9, 2025•
edited
Loading

ldk-reviews-bot commented Jul 8, 2025•
edited
Loading

tnullJul 9, 2025•
edited
Loading

tnullJul 9, 2025•
edited
Loading