Skip to content

Limit full_stack fuzz runtime by limiting block connection ops #3742

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.

Sign up for GitHub

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 1 commit into from
Apr 17, 2025
Merged

Limit full_stack fuzz runtime by limiting block connection ops #3742

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
8 changes: 8 additions & 0 deletions fuzz/src/full_stack.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -299,6 +299,14 @@ impl<'a> MoneyLossDetector<'a> {
}

fn connect_block(&mut self, all_txn: &[Transaction]) {
if self.blocks_connected > 50_000 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Connecting blocks looks like it's interspersed with other fuzz input commands. So now we'll just disallow connecting any blocks after 50k total have been connected? It seems like what we want is more like "allow connecting up to X blocks in a row, then skip connecting any more until we get a fuzz input that does something else"?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sure, but if the fuzzer is doing something interesting it should be able to do it with fewer blocks, so just blindly skipping block connection calls when they get to an absolutely absurd level doesn't seem likely to materially reduce fuzz coverage and is also much simpler :)

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess it just seems like a lot of operations will be limited if no blocks can be connected, particularly channel opens/closes. How can you tell fuzz coverage wasn't reduced?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I mean if something has connected 50k blocks then I'm kinda okay with the rest of that fuzz input getting ignored/not fully processed. The vast majority of inputs shouldn't be connecting that many blocks.

// Connecting blocks is relatively slow, and some commands can connect many blocks.
// This can inflate the total runtime substantially, leading to spurious timeouts.
// Instead, because block connection rate is expected to be limited by PoW, simply
// start ignoring blocks after the first 50k.
return;
}

let mut txdata = Vec::with_capacity(all_txn.len());
for (idx, tx) in all_txn.iter().enumerate() {
let txid = tx.compute_txid();
Expand Down
Loading