Daily cherry-pick#16
Merged
Merged
Conversation
ca93ab8 doc: mention -DWITH_ZMQ=ON in BSD build guides (junbyjun1238) Pull request description: The BSD build guides currently state: > If the package is installed, support will be compiled in. Since `WITH_ZMQ` defaults to `OFF`, this is inaccurate: installing the dependency alone does not enable ZMQ support. Update the wording to mention the required `-DWITH_ZMQ=ON` CMake option, matching `doc/zmq.md`. Docs-only change; no tests run. ACKs for top commit: maflcko: lgtm ACK ca93ab8 sedited: ACK ca93ab8 Tree-SHA512: d07b1b9748d8b6aa555c992608f8659b7e93d6587bbbb2170352342003e90a81592ddfa2abf3a26b8ebf1341142d8628cfc3faba0c4759655a91446afa5fc22a (cherry picked from commit 5309c90)
…uzz_nosan dir 0065f35 doc: clarify libfuzzer-nosan preset uses build_fuzz_nosan dir (ImMike) Pull request description: Adds a clarifying note next to the first mention of the `libfuzzer-nosan` preset in the Quickstart, pointing out that it uses a different build directory (`build_fuzz_nosan`, per [`CMakePresets.json` L54](https://github.com/bitcoin/bitcoin/blob/master/CMakePresets.json#L54)). A reader following the quickstart with `--preset=libfuzzer-nosan` and then running `cmake --build build_fuzz` as shown would otherwise operate against the wrong (or empty) directory. Pure docs; no code changes. ACKs for top commit: l0rinc: ACK 0065f35 maflcko: lgtm ACK 0065f35 sedited: ACK 0065f35 Tree-SHA512: d73901112d259cec58746dff50fe3f9409e5b9826f0759f45478fe039bca851eb163036c60bdb215bfc66be79428b790742bbe8bc32b1ceaa2d6f80c17faf6d0 (cherry picked from commit 04003e1)
032223f dbwrapper: reuse iterator scratch stream (Lőrinc) 7403c0f dbwrapper: guard `CDBBatch` scratch streams (Lőrinc) cb1ab0a test: cover repeated dbwrapper stream use (Lőrinc) 31ce729 streams: add `ScopedDataStreamUsage` (Lőrinc) Pull request description: ### Problem `CDBIterator::GetValue()` cannot use `SpanReader` the same way as `::GetKey()` because values are deobfuscated in place before deserialization, so it still needs an owning mutable buffer. However, the current path allocates a fresh `DataStream` for every value read. The same local-stream pattern also exists in `CDBIterator::Seek()`, while `CDBBatch` already owns reusable key/value buffers but still manually reserves and clears them on every `Write()` and `Erase()` call. ### Fix Add `ScopedDataStreamUsage`, a small RAII helper for caller-owned scratch streams. It asserts that the stream is empty on entry (making accidental re-entry or concurrent use of the same scratch stream fail fast), and clears it on scope exit. Use it to guard the reusable scratch streams in `CDBBatch::Write()`, `::Erase()` and `CDBIterator::Seek()`, `::GetValue()`. The const read-side `CDBWrapper` helpers stay unchanged, since they can be called concurrently on the same wrapper and should keep using local streams. The production changes are preceded by tests covering repeated reuse on the same owning objects, including a failed iterator value decode followed by a successful read from the same iterator entry. ### Context Follow-up to bitcoin#35128, bitcoin#34483 and bitcoin#35025. ### Reproducer `gettxoutsetinfo` gets an additional ~6% speedup on top of the previous iterator-key optimization: <details><summary>2026-04-24 | gettxoutsetinfo | i9-ssd | x86_64 | Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz | 16 cores | 62Gi RAM | xfs | SSD</summary> ```bash COMMITS="2d5ab09f0dca4bfec0b365f5f431def2c0c9d70f 9e5fd59"; \ BASE_DIR="/mnt/my_storage"; DATA_DIR="$BASE_DIR/BitcoinData"; LOG_DIR="$BASE_DIR/logs"; \ mkdir -p "$LOG_DIR" && \ (echo ""; for c in $COMMITS; do git cat-file -e "$c^{commit}" 2>/dev/null || git fetch -q origin "$c" || exit 1; git log -1 --pretty='%h %s' "$c" || exit 1; done) && \ (echo "" && echo "$(date -I) | gettxoutsetinfo | $(hostname) | $(uname -m) | $(lscpu | grep 'Model name' | head -1 | cut -d: -f2 | xargs) | $(nproc) cores | $(free -h | awk '/^Mem:/{print $2}') RAM | $(df -T $BASE_DIR | awk 'NR==2{print $2}') | $(lsblk -no ROTA $(df --output=source $BASE_DIR | tail -1) | grep -q 1 && echo HDD || echo SSD)"; echo "") && \ hyperfine \ --sort command \ --runs 3 \ --export-json "$BASE_DIR/gettxoutsetinfo-$(sed -E 's/([a-f0-9]{8})[a-f0-9]* ?/\1-/g;s/-$//'<<<"$COMMITS")-$(date +%s).json" \ --parameter-list COMMIT ${COMMITS// /,} \ --prepare "killall -9 bitcoind 2>/dev/null || true; rm -f $DATA_DIR/debug.log; git clean -fxd && git reset --hard {COMMIT} && \ cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release && ninja -C build bitcoind bitcoin-cli -j$(nproc) && \ ./build/bin/bitcoind -datadir=$DATA_DIR -connect=0 -listen=0 -dnsseed=0 -coinstatsindex=0 -txindex=0 -blockfilterindex=0 -daemon -printtoconsole=0; \ ./build/bin/bitcoin-cli -datadir=$DATA_DIR -rpcwait getblockcount >/dev/null" \ --conclude "./build/bin/bitcoin-cli -datadir=$DATA_DIR stop 2>/dev/null || true; killall bitcoind 2>/dev/null || true; sleep 10; \ grep -q 'Done loading' $DATA_DIR/debug.log && grep 'Bitcoin Core version' $DATA_DIR/debug.log | grep -q \"\$(git rev-parse --short=12 {COMMIT})\"; \ cp $DATA_DIR/debug.log $LOG_DIR/gettxoutsetinfo-{COMMIT}-$(date +%s).log" \ "./build/bin/bitcoin-cli -datadir=$DATA_DIR -rpcclienttimeout=0 -named gettxoutsetinfo hash_type='none' use_index='false' >/dev/null" 2d5ab09 Merge bitcoin#35124: bench: fix benchmark fixtures and setup checks cb63e15 walletdb: reuse batch scratch streams 2026-04-24 | gettxoutsetinfo | i9-ssd | x86_64 | Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz | 16 cores | 62Gi RAM | xfs | SSD Benchmark 1: ./build/bin/bitcoin-cli -datadir=/mnt/my_storage/BitcoinData -rpcclienttimeout=0 -named gettxoutsetinfo hash_type='none' use_index='false' >/dev/null (COMMIT = 2d5ab09) Time (mean ± σ): 60.063 s ± 1.623 s [User: 0.001 s, System: 0.002 s] Range (min … max): 59.020 s … 61.933 s 3 runs Benchmark 2: ./build/bin/bitcoin-cli -datadir=/mnt/my_storage/BitcoinData -rpcclienttimeout=0 -named gettxoutsetinfo hash_type='none' use_index='false' >/dev/null (COMMIT = cb63e15) Time (mean ± σ): 56.853 s ± 0.179 s [User: 0.002 s, System: 0.001 s] Range (min … max): 56.675 s … 57.033 s 3 runs Relative speed comparison 1.06 ± 0.03 ./build/bin/bitcoin-cli -datadir=/mnt/my_storage/BitcoinData -rpcclienttimeout=0 -named gettxoutsetinfo hash_type='none' use_index='false' >/dev/null (COMMIT = 2d5ab09) 1.00 ./build/bin/bitcoin-cli -datadir=/mnt/my_storage/BitcoinData -rpcclienttimeout=0 -named gettxoutsetinfo hash_type='none' use_index='false' >/dev/null (COMMIT = cb63e15) ``` </details> ACKs for top commit: andrewtoth: re-ACK 032223f CruzMolina: tACK 032223f achow101: ACK 032223f optout21: ACK 032223f sedited: ACK 032223f Tree-SHA512: 6ed51d1a492ca216108b10c01668b01f986260641714951da1d282f1dacf87f0df2b312108f24c06151d3b81eaa4ca6eb4e9ab4e2d829346b0e8f07d0c569a1e (cherry picked from commit a145fa8)
…ce DEBUG_LOCKORDER 801d36f fuzz: use ImmediateBackgroundTaskRunner to silence DEBUG_LOCKORDER (Eugene Siegel) Pull request description: DEBUG_LOCKORDER was reporting a false positive deadlock with the cmpctblock fuzz harness when using ImmediateTaskRunner. Since it is single-threaded, ImmediateTaskRunner callbacks added LockOrders that could never happen outside of a fuzz test. First a block would get connected: * LOCK(mempool.cs) * BlockConnected (fuzz test runs in same thread) * LOCK(m_tx_download_mutex) Then a later iteration of the LIMITED_WHILE would send a TX: * LOCK(m_tx_download_mutex) * LOCK(mempool.cs) causing a false positive deadlock. Normally, the BlockConnected callback would run in a different thread and no deadlock is reported. Fix this by launching a thread that runs the callback and is immediately joined. I compared this PR to another branch (Crypt-iQ@0028847) that uses a ThreadPool and found this PR to be more stable and ~4% quicker. ACKs for top commit: maflcko: lgtm ACK 801d36f sedited: ACK 801d36f Tree-SHA512: 5e1f27354c484a90ffd74a1a11e5fed68d7b38d95c06dd39529217f07d535eb9a5b7befb42b2829d79c52b5eb43542bd1079c81d6eb0e56476352ffe98e0177e (cherry picked from commit 3cab711)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.