This should make the partially_downloaded_block fuzz target even more deterministic.
Follow-up to #31841. Tracking issue: #29018.
This bundles several changes:
- First, speed up the
deterministic-fuzz-coveragehelper by introducing parallelism. - Then, a fix to remove spawned test threads or spawn them deterministically. (While testing this, high parallelism and thread contention may be needed)
Testing
It can be tested via (setting 32 parallel threads):
0cargo run --manifest-path ./contrib/devtools/deterministic-fuzz-coverage/Cargo.toml -- $PWD/bld-cmake/ $PWD/../b-c-qa-assets/fuzz_corpora/ partially_downloaded_block 32
Locally, on a failure, the output would look like:
0 ....
1- 150| 0| m_worker_threads.emplace_back([this, n]() {
2- 151| 0| util::ThreadRename(strprintf("scriptch.%i", n));
3+ 150| 1| m_worker_threads.emplace_back([this, n]() {
4+ 151| 1| util::ThreadRename(strprintf("scriptch.%i", n));
5 ...
This likely indicates that the script threads were started after the fuzz init function returned.
Similarly, for the scheduler thread, it would look like:
0 ...
1 227| 0| m_node.scheduler = std::make_unique<CScheduler>();
2- 228| 1| m_node.scheduler->m_service_thread = std::thread(util::TraceThread, "scheduler", [&] { m_node.scheduler->serviceQueue(); });
3+ 228| 0| m_node.scheduler->m_service_thread = std::thread(util::TraceThread, "scheduler", [&] { m_node.scheduler->serviceQueue(); });
4 229| 0| m_node.validation_signals =
5 ...
