Commit 7562b63
committed
[BUG][GUI] Fix random double/triple transaction record issue
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.
x1 parent 129446a commit 7562b63
1 file changed
+5
-3
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
104 | 104 | | |
105 | 105 | | |
106 | 106 | | |
107 | | - | |
108 | | - | |
109 | | - | |
| 107 | + | |
110 | 108 | | |
111 | 109 | | |
112 | 110 | | |
| |||
153 | 151 | | |
154 | 152 | | |
155 | 153 | | |
| 154 | + | |
| 155 | + | |
| 156 | + | |
| 157 | + | |
156 | 158 | | |
157 | 159 | | |
158 | 160 | | |
| |||
0 commit comments