Limit full_stack fuzz runtime by limiting block connection ops
#3742
Conversation
The `full_stack_target` fuzzer is generally pretty slow, but on some inputs the fuzzer is able to connect hundreds of thousands to millions of blocks, which is by far the slowest operation. In some cases, individual inputs can take tens of minutes to complete, which is not a realistic issue in LDK (we don't expect there to be million-block bursts in Bitcoin) so we simply disable it.
|
I've assigned @jkczyz as a reviewer! |
| } | ||
|
|
||
| fn connect_block(&mut self, all_txn: &[Transaction]) { | ||
| if self.blocks_connected > 50_000 { |
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
4 participants
The
full_stack_targetfuzzer is generally pretty slow, but on some inputs the fuzzer is able to connect hundreds of thousands to millions of blocks, which is by far the slowest operation. In some cases, individual inputs can take tens of minutes to complete, which is not a realistic issue in LDK (we don't expect there to be million-block bursts in Bitcoin) so we simply disable it.