[BUG][GUI] Fix random double/triple transaction record issue #2551
Conversation
This file contains 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
random-zebra
force-pushed
the
202109_qt-tx_update
branch
2 times, most recently
from
9bf0623
to
58b3092
Compare
This bug is caused by the fact that, if at startup the wallet has more than 4000 (SINGLE_THREAD_MAX_TXES_SIZE) transaction records, then chachedWallet is loaded not properly ordered, therfore the binary search (used later in updateWallet, to check whether a tx is already in the model) is unreliable. When the wallet has more than 4000 records, in fact, the list of records in TransactionTablePriv::refreshWallet() is split in batches, each one processed in a separate thread, processing the last batch in the main thread at the beginning, thus without preserving the original order (by hash) of walletTxes. Further, if the wallet has more than 200k records (MAX_AMOUNT_LOADED_RECORDS), then the list is also sorted by date before being trimmed and split in batches. Fix this by re-sorting the cachedWallet list by hash at the end of the multi-threaded update. x
random-zebra
force-pushed
the
202109_qt-tx_update
branch
from
58b3092
to
7562b63
Compare
furszy
approved these changes
Sep 13, 2021
Fuzzbawls
approved these changes
Sep 20, 2021
furszy
referenced
this pull request
in furszy/bitcoin-core
Sep 20, 2021
This bug is caused by the fact that, if at startup the wallet has more than 4000 (SINGLE_THREAD_MAX_TXES_SIZE) transaction records, then chachedWallet is loaded not properly ordered, therfore the binary search (used later in updateWallet, to check whether a tx is already in the model) is unreliable. When the wallet has more than 4000 records, in fact, the list of records in TransactionTablePriv::refreshWallet() is split in batches, each one processed in a separate thread, processing the last batch in the main thread at the beginning, thus without preserving the original order (by hash) of walletTxes. Further, if the wallet has more than 200k records (MAX_AMOUNT_LOADED_RECORDS), then the list is also sorted by date before being trimmed and split in batches. Fix this by re-sorting the cachedWallet list by hash at the end of the multi-threaded update. x Github-Pull: bitcoin#2551 Rebased-From: 7562b63
Fuzzbawls
added a commit
that referenced
this pull request
Sep 21, 2021
2981a17 GUI: Remove unused, and invalid, cached QR pixmap pointer. (furszy) 798c3e9 GUI: addresses widget files overall code cleanup. (furszy) 51f6555 GUI: fix contacts list not being shown. (furszy) 5be181a [Consensus] Add checkpoints before v5.3.1 release Github-Pull: #2562 Rebased-From: e8fddd7 (random-zebra) 17fa0eb Masternode-sync: Only mark tier two messages sync requests as fulfilled if the messages are broadcast. e.g: do not mark them as fulfilled before fail for a timeout. (furszy) 2f98acf [BUG][GUI] Fix random double/triple transaction record issue (random-zebra) 754177e [BUG][TierTwo] Clear fulfilled requests when mnsync fails (random-zebra) 5a2e0d1 [Trivial] Update labelSubtitleAddress text in send widget ui Github-Pull: #2557 Rebased-From: efddb3b (random-zebra) 09b8ec0 [BUG] Spork signer doesn't persist new spork value to DB Github-Pull: #2553 Rebased-From: 5849e3e (random-zebra) 7f827e9 [Snap] Fix nightly build's genbuild.sh patch (Fuzzbawls) 24a1407 [Gitian] Ignore changes to relic_conf.h.in (Fuzzbawls) b400640 Update manpages to reflect newer template (Fuzzbawls) ecdbf86 [Docs] Reformat -help output for help2man (Fuzzbawls) 656be59 Run make translate to update source files (Fuzzbawls) cd8d0b5 Stop translating command line options (Fuzzbawls) 004efe9 Stop translating remaining usages of PACKAGE_NAME (Fuzzbawls) 67e7938 Unify product name to as few places as possible (Fuzzbawls) 4fe9030 [RPC][Doc] Fix RPC/cli example in setautocombinethreshold help (random-zebra) 5f9aac4 Refactor: remove duplicated coll. confirmation check in MNModel::data Github-Pull: #2530 Rebased-From: f0fd8ac (random-zebra) 2a947c0 build: Get rid of `CLIENT_DATE` (Wladimir J. van der Laan) 51fca36 [Qt] Debug window: remove "Build date". (furszy) d223d90 build: Remove src/obj directory from repository (Wladimir J. van der Laan) Pull request description: PRs List: * #2525. * #2530. * #2540. * #2491. * #2541. * #2546. * #2553. * #2557. * #2559. Open PRs that have to get merged to be added here: * * [x] #2560. * * [x] #2555. * * [x] #2551. * * [x] #2562. ACKs for top commit: random-zebra: ACK 2981a17 Fuzzbawls: ACK 2981a17 Tree-SHA512: 400c6cd5c05c99b79c67cb0158048315f33d18a49c9606ad668727b6534c84bbbc8617eb7759b9b6fb230f8fb8b94e74902d03e1579b23b3e84d063ec7a142fa
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Should put the final nail in this coffin, allowing us to finally close #1480.
This bug is caused by the fact that, if at startup the wallet has more than 4000 (
SINGLE_THREAD_MAX_TXES_SIZE) transaction records, then chachedWallet is loaded not properly ordered, therfore the binary search (used later inupdateWallet, to check whether a tx is already in the model) is unreliable.When the wallet has more than 4000 records, in fact, the list of records in
TransactionTablePriv::refreshWallet()is split in batches, each one processed in a separate thread, processing the last batch in the main thread at the beginning, thus without preserving the original order (by hash) ofwalletTxes. Further, if the wallet has more than 200k records (MAX_AMOUNT_LOADED_RECORDS), then the list is also sorted by date before being trimmed and split in batches.Fix this by re-sorting the cachedWallet list by hash at the end of the multi-threaded update.