This PR adds a regression fuzz test for #26355 and some of the bugs found during review of #25717.
Should give us more confidence in doing #25725.
This PR adds a regression fuzz test for #26355 and some of the bugs found during review of #25717.
Should give us more confidence in doing #25725.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
Type | Reviewers |
---|---|
Concept ACK | darosior |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
51+ bool ignore_incoming_txs{false};
52+ bool reconcile_txs{false};
53+ uint32_t max_orphan_txs{DEFAULT_MAX_ORPHAN_TRANSACTIONS};
54+ size_t max_extra_txs{DEFAULT_BLOCK_RECONSTRUCTION_EXTRA_TXN};
55+ bool capture_messages{false};
56+ uint32_t max_headers_result{MAX_HEADERS_RESULTS};
122+void initialize()
123+{
124+ // Reduce proof-of-work check to one bit.
125+ g_check_pow_mock = [](uint256 hash, unsigned int, const Consensus::Params&) {
126+ return (hash.data()[31] & 0x80) == 0;
127+ };
154+ CBlock block = ConsumeBlock(fuzzed_data_provider, prev.GetHash(), prev.nBits);
155+ FinalizeHeader(block);
156+ return block;
157+ };
158+
159+ std::vector<std::function<void()>> actions = {
CallOneOf
another try
I don’t think you can use annotations one way or the other. As soon as you assign to std::function<void()>
, the annotations are dropped, so you might as well not have them in the first place.
If you want them, and use CallOneOf
, you can use the same trick to wrap each annotated lambda into a std::function<void()>{lambda_bla}
temporary to achieve the same result of dropping any annotations.
CallOneOf
and used NO_THREAD_SAFETY_ANALYSIS
.
0test/fuzz/p2p_headers_sync.cpp:187:96: required from here
1./primitives/transaction.h:327:42: error: ‘class CVectorWriter’ has no member named ‘GetParams’
2 327 | SerializeTransaction(*this, s, s.GetParams());
3 | ~~^~~~~~~~~
4make[2]: *** [Makefile:17531: test/fuzz/fuzz-p2p_headers_sync.o] Error 1
5make[2]: Leaving directory '/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src'
6make[1]: *** [Makefile:20246: install-recursive] Error 1
7make[1]: Leaving directory '/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src'
8make: *** [Makefile:811: install-recursive] Error 1
9
10Exit status: 2������������������������������������������������������������������������������������������������������������������������
Needs rebase (silent merge conflict).
Thanks, rebased
121@@ -122,8 +122,14 @@ bool PermittedDifficultyTransition(const Consensus::Params& params, int64_t heig
122 return true;
123 }
124
125+std::function<bool(uint256, unsigned int, const Consensus::Params&)> g_check_pow_mock = nullptr;
126+
127 bool CheckProofOfWork(uint256 hash, unsigned int nBits, const Consensus::Params& params)
128 {
129+ if (g_check_pow_mock) {
params
and whatever applicable global.
FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION
in all places that call CheckProofOfWork
(i.e. validation, mining) since there is literally zero benefit in having this be a blocker for fuzzing.
just fyi, I started reviewing at some point, my problem was that I don’t like test-specific / mocking code in production code (especially the consensus-critical parts), so I wasn’t really comfortable (concept)-acking it. On the other hand, I didn’t see a better way to do it and fuzzing is great obviously…
As a result, I was undecided and didn’t write anything. Maybe it’d be worth to have a general discussion about the extent of mocking / test-specific production code we want as a project, since there are obviously both advantages and disadvantages to it. If there was a general consensus that these kind of mocks are fine I’d be happy to review/ack the actual fuzz target.
assert(params!=main)
(https://github.com/bitcoin/bitcoin/pull/28043#discussion_r1446512814) should be fine.