| Age | Commit message (Collapse) | Author |
|---|
|
It encapsulates a given linearization in chunked form, permitting arbitrary
subsets of transactions to be removed from the linearization. Its purpose
is adding the Intersect function, which is a crucial operation that will
be used in a further commit to make Linearize improve existing linearizations.
|
|
To make search non-deterministic, change the BFS logic from always picking
the first queue item to randomly picking the first or second queue item.
|
|
Switch to BFS exploration of the search tree in SearchCandidateFinder
instead of DFS exploration. This appears to behave better for real
world clusters.
As BFS has the downside of needing far larger search queues, switch
back to DFS temporarily when the queue grows too large.
|
|
Add benchmarks for known bad graphs for the purpose of search (as
an upper bound on work per search iterations) and ancestor sorting
(as an upper bound on linearization work with no search iterations).
|
|
This adds a first version of the overall linearization interface, which given
a DepGraph constructs a good linearization, by incrementally including good
candidate sets (found using AncestorCandidateFinder and SearchCandidateFinder).
|
|
A fuzz test is added which verifies various of its expected properties, including
correctness
|
|
Similar to AncestorCandidateFinder, this encapsulates the state needed for
finding good candidate sets using a search algorithm.
|
|
This is a class that encapsulates precomputed ancestor set feerates, and
presents an interface for getting the best remaining ancestor set.
|
|
This introduces a bespoke fuzzing-focused serialization format for DepGraphs,
and then tests that this format can represent any graph, roundtrips, and then
uses that to test the correctness of DepGraph itself.
This forms the basis for future fuzz tests that need to work with interesting
graphs.
|
|
This primarily adds the DepGraph class, which encapsulates precomputed
ancestor/descendant information for a given transaction cluster, with a
number of utility features (inspectors for set feerates, computing
reduced parents/children, adding transactions, adding dependencies), which
will become needed in future commits.
|
|
7c29e556c573a63351096c34bc072ae0c60ffa29 m_tx_download_mutex followups (glozow)
e543c657dad830294609424b459755884bd44f3c release m_tx_download_mutex before MakeAndPushMessage GETDATA (glozow)
bce5f37c7bef2755e8d5f0886f37dd58357dadad [refactor] change ActiveTipChange to use CBlockIndex ref instead of ptr (glozow)
7cc5ac5a674f31af2ac7e5b5842e1c1aeb9e6744 [doc] TxOrphanage is no longer thread-safe (glozow)
6f49548670d5ab12a963c0ada3b315c544b95e2e [refactor] combine block vtx loops in BlockConnected (glozow)
Pull request description:
Followup to #30111. Includes suggestions:
- https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1686303768
- https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1686314984
- https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1683186792
- https://github.com/bitcoin/bitcoin/pull/30111#issuecomment-2242819514
- https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1686372826
ACKs for top commit:
instagibbs:
reACK https://github.com/bitcoin/bitcoin/pull/30507/commits/7c29e556c573a63351096c34bc072ae0c60ffa29
theStack:
re-ACK 7c29e556c573a63351096c34bc072ae0c60ffa29
dergoegge:
reACK 7c29e556c573a63351096c34bc072ae0c60ffa29
Tree-SHA512: 79a9002d74739367789bbc64bb1d431f4d43a25a7934231e55814c2cb6981c15ef2d8465544ae2a4fbd734d9bed6cc41b37a923938a88cb8fea139523c1e98da
|
|
TestingSetup
f46b2202560a76b473e229b77303b8f877c16cac fuzz: Use BasicTestingSetup for coins_view target (TheCharlatan)
9e2a723d5da4fc277a42fed37424f578e348ebf8 test: Add arguments for creating a slimmer setup (TheCharlatan)
Pull request description:
This adds arguments to some of the testing setup constructors for creating an environment without networking and a validation interface. This is useful for improving the performance of the utxo snapshot fuzz test, which constructs a new TestingSetup on each iteration.
Using this slimmed down `TestingSetup` in future might also make the tests a bit faster when run in aggregate.
ACKs for top commit:
maflcko:
review ACK f46b2202560a76b473e229b77303b8f877c16cac
dergoegge:
utACK f46b2202560a76b473e229b77303b8f877c16cac
Tree-SHA512: 9dc62512b127b781fc9e2d8ef2b5a9b06ebb927a8294b6d872001c553984a7eb1f348e0257b32435b34b5505b5d0323f73bdd572a673da272d3e1e8538ab49d6
|
|
getutxos parsing
fac0c3d4bfc97b94f0594f7606650921feef2c8a doc: Add release notes for two pull requests (MarcoFalke)
fa7b57e5f5a6dafbbadc361ffd27b58afff1ed59 refactor: Replace ParseHashStr with FromHex (MarcoFalke)
fa9077724507faad207f29509a8202fc6ac9d502 rest: Reject truncated hex txid early in getutxos parsing (MarcoFalke)
fab6ddbee64e50d5e2f499aebca35b5911896ec4 refactor: Expose FromHex in transaction_identifier (MarcoFalke)
fad2991ba073de0bd1f12e42bf0fbaca4a265508 refactor: Implement strict uint256::FromHex() (MarcoFalke)
fa103db2bb736bce4440f0bde564e6671e36311d scripted-diff: Rename SetHex to SetHexDeprecated (MarcoFalke)
fafe4b80512a5a82712a3ee81b68cfeb21271dee test: refactor: Replace SetHex with uint256 constructor directly (MarcoFalke)
Pull request description:
In `rest_getutxos` truncated txids such as `aa` or `ff` are accepted. This is brittle at best.
Fix it by rejecting any truncated (or overlarge) input.
----
Review note: This also starts a major refactor to rework hex parsing in Bitcoin Core, meaning that a few refactor commits are included as well. They are explained individually in the commit message and the work will be continued in the future.
ACKs for top commit:
stickies-v:
re-ACK fac0c3d4bfc97b94f0594f7606650921feef2c8a - only doc and test updates to address review comments, thanks!
hodlinator:
ACK fac0c3d4bfc97b94f0594f7606650921feef2c8a
Tree-SHA512: 473feb3fcf6118443435d1dd321006135b0b54689bfbbcb1697bb5811a449bef51f475c715de6911ff3c4ea3bdb75f601861ff93347bc4414d6b9e5298105dd7
|
|
The message is not exposed in the GUI or another translated context, so
translating it is useless for now.
Also, fix a nit from https://github.com/bitcoin/bitcoin/pull/30395#discussion_r1670972864
|
|
- add AssertLockNotHeld(m_tx_download_mutex) in net_processing
- move doc about m_tx_download_mutex and mempool mutex to ActiveTipChange
|
|
|
|
|
|
default mode to `economical`
25bf86a225b0df3f48ade1016b47f5ee1636b988 [test]: ensure `estimatesmartfee` default mode is `economical` (ismaelsadeeq)
41a2545046bce315af697a3c6baf6e3fb2e824c2 [fees]: change `estimatesmartfee` default mode to `economical` (ismaelsadeeq)
Pull request description:
Fixes #30009
This PR changes the `estimatesmartfee` default mode to `economical`.
This was also suggested on IRC https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2024-04-26#1021609
- `conservative` mode: This is the `estimatesmartfee` RPC mode which considers a longer history of blocks. It potentially returns a higher fee rate and is more likely to be sufficient for the desired target, but it is not as responsive to short-term drops in the prevailing fee market.
- `economical` mode: This is the `estimatesmartfee` RPC mode where estimates are potentially lower and more responsive to short-term drops in the prevailing fee market.
Since users are likely to use the default mode, this change will reduce overestimation for many users. The conservative mode remains available for those who wish to opt-in.
For an in-depth analysis of how significantly the `conservative` mode overestimates, see
https://delvingbitcoin.org/t/bitcoind-policy-estimator-modes-analysis/964.
ACKs for top commit:
instagibbs:
reACK https://github.com/bitcoin/bitcoin/pull/30275/commits/25bf86a225b0df3f48ade1016b47f5ee1636b988
glozow:
ACK 25bf86a225b0df3f48ade1016b47f5ee1636b988
willcl-ark:
ACK 25bf86a225b0df3f48ade1016b47f5ee1636b988
Tree-SHA512: 78ebda667eb9c8f87dcc2f0e6c14968bd1de30358dc77a13611b186fb8427ad97d9f537bad6e32e0a1aa477ccd8c64fee4d41e19308ef3cb184ff1664e6ba8a6
|
|
No need to have two functions with different names that achieve the
exact same thing.
|
|
|
|
This is needed for the next commit.
|
|
This is a safe replacement of the previous SetHex, which now returns an
optional to indicate success or failure.
The code is similar to the ParseHashStr helper, which will be removed in
a later commit.
|
|
These cause compile failures with _LIBCPP_REMOVE_TRANSITIVE_INCLUDES.
i.e:
```bash
In file included from init.cpp:8:
./init.h:46:54: error: no template named 'atomic' in namespace 'std'
46 | bool AppInitBasicSetup(const ArgsManager& args, std::atomic<int>& exit_status);
| ~~~~~^
1 error generated.
```
See: https://libcxx.llvm.org/DesignDocs/HeaderRemovalPolicy.html.
|
|
|
|
Now that m_txrequest and m_recent_confirmed_transactions are guarded by
the same mutex, there is no benefit to processing them separately.
Instead, just loop through pblock->vtx once.
|
|
|
|
rejection filters once per tip change
c85accecafc20f6a6ae94bdf6cdd3ba9747218fd [refactor] delete EraseTxNoLock, just use EraseTx (glozow)
6ff84069a5dd92303ed2ec28f0ec7c96bbda3938 remove obsoleted TxOrphanage::m_mutex (glozow)
61745c7451ec64b26c74f672c688e82efb3b96aa lock m_recent_confirmed_transactions using m_tx_download_mutex (glozow)
723ea0f9a5b5e3f3f58ea049a98299ff0ebde468 remove obsoleted hashRecentRejectsChainTip (glozow)
18a43552509603ddf83b752fd7b4b973ba1dcf82 update recent_rejects filters on ActiveTipChange (glozow)
36f170d87924e50d0ff9be2a1b0f2a8f13950a9b add ValidationInterface::ActiveTipChange (glozow)
3eb1307df0a38ac4ea52995fbb03ead37387b41e guard TxRequest and rejection caches with new mutex (glozow)
Pull request description:
See #27463 for full project tracking.
This contains the first few commits of #30110, which require some thinking about thread safety in review.
- Introduce a new `m_tx_download_mutex` which guards the transaction download data structures including `m_txrequest`, the rolling bloom filters, and `m_orphanage`. Later this should become the mutex guarding `TxDownloadManager`.
- `m_txrequest` doesn't need to be guarded using `cs_main` anymore
- `m_recent_confirmed_transactions` doesn't need its own lock anymore
- `m_orphanage` doesn't need its own lock anymore
- Adds a new `ValidationInterface` event, `ActiveTipChanged`, which is a synchronous callback whenever the tip of the active chainstate changes.
- Flush `m_recent_rejects` and `m_recent_rejects_reconsiderable` on `ActiveTipChanged` just once instead of checking the tip every time `AlreadyHaveTx` is called. This should speed up calls to that function (no longer comparing a block hash each time) and removes the need to lock `cs_main` every time it is called.
Motivation:
- These data structures need synchronization. While we are holding `m_tx_download_mutex`, these should hold:
- a tx hash in `m_txrequest` is not also in `m_orphanage`
- a tx hash in `m_txrequest` is not also in `m_recent_rejects` or `m_recent_confirmed_transactions`
- In the future, orphan resolution tracking should also be synchronized. If a tx has an entry in the orphan resolution tracker, it is also in `m_orphanage`, and not in `m_txrequest`, etc.
- Currently, `cs_main` is used to e.g. sync accesses to `m_txrequest`. We should not broaden the scope of things it locks.
- Currently, we need to know the current chainstate every time we call `AlreadyHaveTx` so we can decide whether we should update it. Every call compares the current tip hash with `hashRecentRejectsChainTip`. It is more efficient to have a validation interface callback that updates the rejection filters whenever the chain tip changes.
ACKs for top commit:
instagibbs:
reACK c85accecafc20f6a6ae94bdf6cdd3ba9747218fd
dergoegge:
Code review ACK c85accecafc20f6a6ae94bdf6cdd3ba9747218fd
theStack:
Light code-review ACK c85accecafc20f6a6ae94bdf6cdd3ba9747218fd
hebasto:
ACK c85accecafc20f6a6ae94bdf6cdd3ba9747218fd, I have reviewed the code and it looks OK.
Tree-SHA512: c3bd524b5de1cafc9a10770dadb484cc479d6d4c687d80dd0f176d339fd95f73b85cb44cb3b6b464d38a52e20feda00aa2a1da5a73339e31831687e4bd0aa0c5
|
|
Instead of constructing a new class every time a file operation is done,
construct them once for each of the undo and block file when a new
BlockManager is created.
In future, this might make it easier to introduce an abstract block
store.
|
|
SetHex is fragile, because it accepts any non-hex input or any length of
input, without error feedback. This can lead to issues when the input is
truncated or otherwise corrupted.
Document the problem by renaming the method.
In the future, the fragile method should be removed from the public
interface.
-BEGIN VERIFY SCRIPT-
sed -i 's/SetHex/SetHexDeprecated/g' $( git grep -l SetHex ./src )
-END VERIFY SCRIPT-
|
|
This avoids a hex-decoding and makes the next commit smaller.
|
|
length
09ce3501fa2ea2885a857e380eddb74605f7038c fix: Make TxidFromString() respect string_view length (Hodlinator)
01e314ce0ae30228742b6f19d2f12a050ab97e4d refactor: Change base_blob::SetHex() to take std::string_view (Hodlinator)
2f5577dc2e7ba668798a89a2f6ef72795db6c285 test: uint256 - Garbage suffixes and zero padding (Hodlinator)
f11f816800ac520064a1e96871d0b4cc9601ced7 refactor: Make uint256_tests no longer use deprecated BOOST_CHECK() (Hodlinator)
f0eeee2dc1329b0647df09bea9ccc0395bb82698 test: Add test for TxidFromString() behavior (Ryan Ofsky)
Pull request description:
### Problem
Prior to this, `TxidFromString()` was passing `string_view::data()` into `uint256S()` which meant it would only receive the a naked `char*` pointer and potentially scan past the `string_view::length()` until it found a null terminator (or some other non-hex character).
Appears to have been a fully dormant bug as callers were either passing a string literal or `std::string` directly to `TxidFromFromString()`, meaning a null terminator always existed at `pointer[length()]`. Bug existed since original merge of `TxidFromString()`.
### Solution
Make `uint256S()` (and `base_blob::SetHex()`) take and operate on `std::string_view` instead of `const char*` and have `TxidFromString()` pass that in.
(PR was prompted by comment in https://github.com/bitcoin/bitcoin/pull/30377#issuecomment-2208857200 (referring to https://github.com/bitcoin/bitcoin/pull/28922#discussion_r1404437378)).
ACKs for top commit:
maflcko:
re-ACK 09ce3501fa2ea2885a857e380eddb74605f7038c 🕓
paplorinc:
ACK 09ce3501fa2ea2885a857e380eddb74605f7038c
ryanofsky:
Code review ACK 09ce3501fa2ea2885a857e380eddb74605f7038c. I think the current code changes are about as small as you could make to fix the bug without introducing a string copy, and the surrounding test improvements are all very nice and welcome.
Tree-SHA512: c2c10551785fb6688d1e2492ba42a8eee4c19abbe8461bb0774d56a70c23cd6b0718d2641632890bee880c06202dee148126447dd2264eaed4f5fee7e1bcb581
|
|
consistently in "asm"/"hex" results
29eafd5733d77b3e8f3f3ab6cd65c61ac0e8536b rpc: doc: use "output script" terminology consistently in "asm"/"hex" results (Sebastian Falbesoner)
Pull request description:
The wording "public key script" was likely chosen as a human-readable form of the technical term `scriptPubKey`, but it doesn't seem to be really widespread. Replace it by the more (probably most?) common term "output script" instead. Note that the argument for the `decodescript` RPC is not necessarily an output script (it could e.g. be also a redeem script), so in this case we just stay generic and use "script".
See also the draft BIP "Terminology for Transaction Components" (https://github.com/murchandamus/bips/blob/2022-04-tx-terminology/bip-tx-terminology.mediawiki) from murchandamus which suggests to use "output script" as well.
Affects the help text of the following RPCs:
- decodepsbt
- decoderawtransaction
- decodescript
- getblock (if verbosity=3)
- getrawtransaction (if verbosity=2,3)
- gettxout
ACKs for top commit:
maflcko:
ACK 29eafd5733d77b3e8f3f3ab6cd65c61ac0e8536b
achow101:
ACK 29eafd5733d77b3e8f3f3ab6cd65c61ac0e8536b
BrandonOdiwuor:
ACK 29eafd5733d77b3e8f3f3ab6cd65c61ac0e8536b
tdb3:
ACK 29eafd5733d77b3e8f3f3ab6cd65c61ac0e8536b
Tree-SHA512: 62eb92d42bc44e36dc3090df7b248a123868a74af253d2046de02086e688bf6ff98307b927ba2fee3d599f85e073aeb8eca90ed15105ca63b648b6796cfa340b
|
|
Otherwise, the debug log could read confusingly, when the getpeerinfo()
RPC (calling GetNodeStats) happens after the "accepted connection" log
line, but returns an empty list.
For example, the following timeline in the debug log could correspond to
a getpeerinfo reply that is empty:
[net] [net.cpp:3764] [CNode] Added connection peer=0
[net] [net.cpp:1814] [CreateNodeFromAcceptedSocket] connection from 127.0.0.1:45154 accepted
[http] [httpserver.cpp:305] [http_request_cb] Received a POST request for / from 127.0.0.1:33320
[httpworker.1] [rpc/request.cpp:232] [parse] ThreadRPCServer method=getpeerinfo user=__cookie__
Fix it by moving the log line.
|
|
Prior to this, passing string_view::data() into uint256S() meant the latter would only receive the a naked char* pointer and potentially scan past the string_view::length() until it found a null terminator (or some other non-hex character).
Appears to have been a fully dormant bug as callers were either passing a string literal or std::string directly to TxidFromFromString(), meaning null terminator always existed at pointer[length()]. Bug existed since original merge of TxidFromString(), discussed in https://github.com/bitcoin/bitcoin/pull/28922#discussion_r1404437378.
|
|
Clarify that hex strings are parsed as little-endian.
|
|
|
|
CTxMemPool::cs
6a5e9e40e1dd3d397020703feb9aa0b6f4577c98 doc: use proper doxygen formatting for CTxMemPool::cs (Vasil Dimov)
Pull request description:
Having `@par title` followed by an empty line renders improperly in Doxygen - it results in a paragraph with a title but without a body.
https://www.doxygen.nl/manual/commands.html#cmdpar
This also results in a compiler warning (or error) with Clang 19:
```
./txmempool.h:368:34: error: empty paragraph passed to '@par' command [-Werror,-Wdocumentation]
368 | * @par Consistency guarantees
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^
1 error generated.
```
ACKs for top commit:
maflcko:
review ACK 6a5e9e40e1dd3d397020703feb9aa0b6f4577c98
tdb3:
ACK 6a5e9e40e1dd3d397020703feb9aa0b6f4577c98
Tree-SHA512: 2c4c9e5fd4bd44754800a9bcfff74df101afc060b84451c45aa098e4ceb05a47f28a36f8473b31222552fad6339b752a148e6b1c7d41c2003f515b3eb4060902
|
|
|
|
|
|
Having `@par title` followed by an empty line renders improperly in
Doxygen - it results in a paragraph with a title but without a body.
https://www.doxygen.nl/manual/commands.html#cmdpar
This also results in a compiler warning (or error) with Clang 19:
```
./txmempool.h:368:34: error: empty paragraph passed to '@par' command [-Werror,-Wdocumentation]
368 | * @par Consistency guarantees
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^
1 error generated.
```
|
|
Co-Authored-By: l0rinc <pap.lorinc@gmail.com>
|
|
target
dcb4ec944984961e3b40452425a219e15e6ab508 fuzz: reduce keypool size in scriptpubkeyman target (brunoerg)
Pull request description:
Fixes #30476
This PR reduces keypool size in scriptpubkeyman fuzz target to avoid spend a lot of time in `TopUp` (which is obviously called by many spkm functions).
For reference:
This PR:
```
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 1845055748
INFO: Loaded 1 modules (1225616 inline 8-bit counters): 1225616 [0x106346fe0, 0x106472370),
INFO: Loaded 1 PC tables (1225616 PCs): 1225616 [0x106472370,0x107725c70),
./src/test/fuzz/fuzz: Running 1 inputs 10 time(s) each.
Running: ./qa-assets/fuzz_seed_corpus/scriptpubkeyman/c9b8928cecb1edc192fb2d5816b4b7878cdfcf50
Executed ./qa-assets/fuzz_seed_corpus/scriptpubkeyman/c9b8928cecb1edc192fb2d5816b4b7878cdfcf50 in 250 ms
```
Master:
```
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 2004906948
INFO: Loaded 1 modules (1225603 inline 8-bit counters): 1225603 [0x104196f80, 0x1042c2303),
INFO: Loaded 1 PC tables (1225603 PCs): 1225603 [0x1042c2308,0x105575b38),
./src/test/fuzz/fuzz: Running 1 inputs 10 time(s) each.
Running: ./qa-assets/fuzz_seed_corpus/scriptpubkeyman/c9b8928cecb1edc192fb2d5816b4b7878cdfcf50
Executed ./qa-assets/fuzz_seed_corpus/scriptpubkeyman/c9b8928cecb1edc192fb2d5816b4b7878cdfcf50 in 21016 ms
```
ACKs for top commit:
maflcko:
review ACK dcb4ec944984961e3b40452425a219e15e6ab508
dergoegge:
utACK dcb4ec944984961e3b40452425a219e15e6ab508
Tree-SHA512: d818b228d5f1dd0d5c665d8e54cf5dd8e378604039eaac114fc34366ece4420b9b2519d898f2dc2410960b873f0b91bbad4a534a35658477aed6ef48f3458137
|
|
These warnings were often polluting the CI output, e.g. https://github.com/bitcoin/bitcoin/pull/30499/checks?check_run_id=27745036545
> ./test/lint/lint-spelling.py
before the change:
```
doc/design/libraries.md:100: targetted ==> targeted
doc/developer-notes.md:495: dependant ==> dependent
src/bench/sign_transaction.cpp:49: hashIn ==> hashing, hash in
src/bitcoin-chainstate.cpp:213: hashIn ==> hashing, hash in
src/bitcoin-chainstate.cpp:213: hashIn ==> hashing, hash in
src/coins.cpp:24: viewIn ==> viewing, view in
src/coins.cpp:24: viewIn ==> viewing, view in
src/coins.cpp:29: viewIn ==> viewing, view in
src/coins.cpp:29: viewIn ==> viewing, view in
src/coins.h:44: outIn ==> outing, out in
src/coins.h:44: outIn ==> outing, out in
src/coins.h:45: outIn ==> outing, out in
src/coins.h:45: outIn ==> outing, out in
src/coins.h:215: viewIn ==> viewing, view in
src/coins.h:220: viewIn ==> viewing, view in
src/primitives/transaction.h:37: hashIn ==> hashing, hash in
src/primitives/transaction.h:37: hashIn ==> hashing, hash in
src/protocol.cpp:51: hashIn ==> hashing, hash in
src/protocol.cpp:51: hashIn ==> hashing, hash in
src/protocol.h:497: hashIn ==> hashing, hash in
src/qt/forms/optionsdialog.ui:344: incomin ==> incoming
src/qt/optionsdialog.cpp:445: proxys ==> proxies
src/rpc/mining.cpp:987: hashIn ==> hashing, hash in
src/rpc/mining.cpp:987: hashIn ==> hashing, hash in
src/script/interpreter.h:298: amountIn ==> amounting, amount in
src/script/interpreter.h:298: amountIn ==> amounting, amount in
src/script/interpreter.h:299: amountIn ==> amounting, amount in
src/script/interpreter.h:299: amountIn ==> amounting, amount in
src/script/sigcache.h:70: amountIn ==> amounting, amount in
src/script/sigcache.h:70: amountIn ==> amounting, amount in
src/signet.cpp:144: amountIn ==> amounting, amount in
src/test/fuzz/util/net.cpp:386: occured ==> occurred
src/test/fuzz/util/net.cpp:398: occured ==> occurred
src/util/vecdeque.h:79: deques ==> dequeues
src/util/vecdeque.h:160: deques ==> dequeues
src/util/vecdeque.h:184: deques ==> dequeues
src/util/vecdeque.h:194: deques ==> dequeues
src/validation.cpp:2130: re-declared ==> redeclared
src/validation.h:348: outIn ==> outing, out in
src/validation.h:349: outIn ==> outing, out in
test/functional/wallet_bumpfee.py:851: atleast ==> at least
```
|
|
fa80b16b20dffcb85b80f75fee64ed333f2062f9 fuzz: Limit parse_univalue input length (MarcoFalke)
Pull request description:
The new limit should be more than enough, and hopefully avoids fuzz input bloat, such as `parse_univalue/0426365704e09ddd704a058cc2add1cbf104c1a9`. C.f. https://cirrus-ci.com/task/6178647134961664?logs=ci#L3805
```
Run parse_univalue with args ['/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/fuzz', '-runs=1', PosixPath('/ci_container_base/ci/scratch/qa-assets/fuzz_seed_corpus/parse_univalue')]INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 572704560
INFO: Loaded 1 modules (623498 inline 8-bit counters): 623498 [0x561cba23a518, 0x561cba2d28a2),
INFO: Loaded 1 PC tables (623498 PCs): 623498 [0x561cba2d28a8,0x561cbac56148),
INFO: 3224 files found in /ci_container_base/ci/scratch/qa-assets/fuzz_seed_corpus/parse_univalue
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 1048576 bytes
INFO: seed corpus: files: 3224 min: 1b max: 1050370b total: 25114084b rss: 112Mb
#1024pulse cov: 10458 ft: 33444 corp: 906/32Kb exec/s: 341 rss: 154Mb
#2048pulse cov: 12081 ft: 55461 corp: 1668/192Kb exec/s: 227 rss: 228Mb
Slowest unit: 15 s:
artifact_prefix='./'; Test unit written to ./slow-unit-9df6997f2f4726843e82b3dfde46862599904d56
Slowest unit: 309 s:
artifact_prefix='./'; Test unit written to ./slow-unit-0426365704e09ddd704a058cc2add1cbf104c1a9
#3226INITED cov: 12246 ft: 66944 corp: 2358/3510Kb exec/s: 6 rss: 1610Mb
#3226DONE cov: 12246 ft: 66944 corp: 2358/3510Kb lim: 282379 exec/s: 6 rss: 1610Mb
Done 3226 runs in 477 second(s)
ACKs for top commit:
dergoegge:
utACK fa80b16b20dffcb85b80f75fee64ed333f2062f9
brunoerg:
utACK fa80b16b20dffcb85b80f75fee64ed333f2062f9
Tree-SHA512: b2ffbaaa4876be61be0e6c975ab65a842562d14079a13836202f8b5b5ef75e068e73df75c9bcc702379e123fcdb1dcd66951e31533fb4aaa6afe17dff160f7d0
|
|
|
|
When using CMake, the user can select the MSVC runtime library to be:
1) Statically-linked (with the corresponding `x64-windows-static` vcpkg
triplet) or
2) Dynamically-linked (with the corresponding `x64-windows` vcpkg
triplet)
In the latter case, the compiler emits the C4273 warning.
As the "Necessary on some platforms" comment does not apply to MSVC,
skip the declaration for MSVC.
|
|
The body of the fuzz test should ideally be a pure function. If data is
persisted in the cache over many iterations, and there is a crash,
reproducing it from the input might be difficult.
|
|
|
|
|
|
|
