fuzz: Speed up dbwrapper_concurrent_reads harness
What the developer wrote
Authored by marcofleon
fuzz: Speed up dbwrapper_concurrent_reads harness
Limit how many read queries each worker executes. This significantly
speeds up the test, as each worker runs >90% fewer (2000 to 128)
expensive LevelDB operations (like `IteratorSeek`) but still
ends up hitting the intended target code.
Revert the `num_entries` max from 3000 back to 5000, as that didn't
have much effect on input speed and restores a bit of lost coverage.
What changed, and why it matters
This commit only changes a fuzz test (an automated testing harness) for Bitcoin Core's database wrapper. It reduces how many read operations each simulated worker thread performs during the test, which makes the test run faster, and increases the maximum number of database entries back to a previous value to keep test coverage. There is no change to production code, no user-facing behavior change, and no security fix.
No action required. This is a benign test-only optimization.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch modifies src/test/fuzz/dbwrapper.cpp, a fuzzing target. It introduces a constant MAX_READ_QUERIES_PER_WORKER set to 128 and limits each worker thread to run at most that many queries from its shuffled query list, using std::span. It also reverts the num_entries range maximum from 3,000 to 5,000. These are purely test-performance and coverage tuning changes inside a fuzz harness; no runtime consensus, networking, wallet, or database logic is altered.
Changed components
src/test/fuzz/dbwrapper.cppInspect captured patch +7 / −2
diff --git a/src/test/fuzz/dbwrapper.cpp b/src/test/fuzz/dbwrapper.cpp
index 1b5cd7b0..8f1d84e4 100644
--- a/src/test/fuzz/dbwrapper.cpp
+++ b/src/test/fuzz/dbwrapper.cpp
@@ -30,6 +30,7 @@
#include <numeric>
#include <optional>
#include <set>
+#include <span>
#include <string>
#include <tuple>
#include <vector>
@@ -169,6 +170,9 @@ void VerifyIterator(CDBWrapper& dbw, const Oracle& oracle,
/** Maximum number of concurrent reader threads in dbwrapper_concurrent_reads. */
constexpr size_t MAX_READ_WORKERS{8};
+/** Maximum number of queries each worker executes in dbwrapper_concurrent_reads. */
+constexpr size_t MAX_READ_QUERIES_PER_WORKER{128};
+
ThreadPool g_read_pool{"dbfuzz"};
Mutex g_read_pool_mutex;
@@ -371,7 +375,7 @@ FUZZ_TARGET(dbwrapper_concurrent_reads, .init = [] { static auto setup{MakeNoLog
// Seed the DB. Drain work after small batches so we don't deadlock on a
// scheduled compaction.
- const size_t num_entries{provider.ConsumeIntegralInRange<size_t>(100, 3'000)};
+ const size_t num_entries{provider.ConsumeIntegralInRange<size_t>(100, 5'000)};
std::vector<uint16_t> keys;
keys.reserve(num_entries);
Oracle oracle;
@@ -416,12 +420,13 @@ FUZZ_TARGET(dbwrapper_concurrent_reads, .init = [] { static auto setup{MakeNoLog
std::vector<size_t> order(queries.size());
std::iota(order.begin(), order.end(), size_t{0});
std::ranges::shuffle(order, thread_rng);
+ const size_t queries_to_run{std::min(queries.size(), MAX_READ_QUERIES_PER_WORKER)};
std::vector<uint8_t> v;
std::string key_str;
start_latch.arrive_and_wait();
const std::unique_ptr<CDBIterator> it{db.NewIterator()};
// Every read must agree with the oracle, the source of truth.
- for (const auto i : order) {
+ for (const auto i : std::span{order}.first(queries_to_run)) {
const auto& [op, key] = queries[i];
switch (op) {
case ReadOp::Read:
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.