New global variables were introduced in #11403 and not setting them causes:
test_bitcoin: wallet/wallet.cpp:4259: CTxDestination GetDestinationForKey(const CPubKey&, OutputType): Assertion `false' failed.
unknown location(0): fatal error in "importwallet_rescan": signal: SIGABRT (application abort requested)
It's possible to reproduce the failure reliably by running:
src/test/test_bitcoin --log_level=test_suite --run_test=wallet_tests/importwallet_rescan
Failures happen nondeterministically because boost test framework doesn't run
tests in a specified order, and tests that run previously can set the global
variables and mask the bug.
Github-Pull: #12424
Rebased-From: b7f6002ed5d12b461eb56b768d06f2468cd0c12e
Tree-SHA512: 1cc64db3b1d886d793e9d194b318dde3d5f628bde778a50513de4bf54dcfc77152885e72608927e3e490d253350ca0381847539a904cb31862f3a6fceac88dc1
New global variables were introduced in #11403 and not setting them causes:
test_bitcoin: wallet/wallet.cpp:4199: CTxDestination GetDestinationForKey(const CPubKey&, OutputType): Assertion `false' failed.
unknown location(0): fatal error in "ListCoins": signal: SIGABRT (application abort requested)
It's possible to reproduce the failure reliably by running:
src/test/test_bitcoin --log_level=test_suite --run_test=wallet_tests/ListCoins
Failures happen nondeterministically because boost test framework doesn't run
tests in a specified order, and tests that run previously can set the global
variables and mask the bug.
This requires the removal of some very liberal (incorrect) cs_mains
sprinkled in some tests. It adds some chainActive.Tip() races, but
the tests are all single-threaded anyway.
CWallet::MarkConflicted may acquire the cs_main lock after
CWalletDB::LoadWallet acquires the cs_wallet lock during wallet initialization.
(CWalletDB::LoadWallet calls ReadKeyValue which calls CWallet::LoadToWallet
which calls CWallet::MarkConflicted). This is the opposite order that cs_main
and cs_wallet locks are acquired in the rest of the code, and so leads to
POTENTIAL DEADLOCK DETECTED errors if bitcoin is built with -DDEBUG_LOCKORDER.
This commit changes CWallet::LoadWallet (which calls CWalletDB::LoadWallet) to
acquire both locks in the standard order. It also fixes some tests that were
acquiring wallet and main locks out of order and failed with the new locking in
CWallet::LoadWallet.
Error was reported by Luke Dashjr <luke-jr@utopios.org> in
https://botbot.me/freenode/bitcoin-core-dev/msg/90244330/
This assures that we don't overwrite a random file called
`wallet.backup` that happens to be in the current directory. It also
assures that the temporary file will be cleaned up.
Noticed by Evan Klitzke, came up in discussion here:
https://github.com/bitcoin/bitcoin/pull/10880#discussion_r128460722
Start importwallet rescans at the first block with timestamp greater or equal
to the wallet birthday instead of the last block with timestamp less or equal.
This fixes an edge case bug where importwallet could fail to start the rescan
early enough if there are blocks with decreasing timestamps or multiple blocks
with the same timestamp.
An off-by-one-block bug in importmulti rescan logic could cause it to return
success in an edge case even when a rescan was not successful. The case where
this would happen is if there were multiple blocks in a row with the same
GetBlockTimeMax() value, and the last block was scanned successfully, but one
or more of the earlier blocks was not readable.
Change ScanForWalletTransactions return value so it is possible to distinguish
scans that skip reading every block (due to the nTimeFirstKey optimization)
from scans that fail while reading the chainActive.Tip() block. Return value is
now non-null in the non-failing case.
This change doesn't affect any user-visible behavior, it is only an internal
API improvement. The only code currently using the ScanForWalletTransactions
return value is in importmulti, and importmulti always calls
ScanForWalletTransactions with a pindex pointing to the first block in
chainActive whose block time is >= (nLowestTimestamp - 7200), while
ScanForWalletTransactions would only return null without reading blocks when
pindex and every block after it had a block time < (nTimeFirstKey - 7200).
These conditions could never happen at the same time because nTimeFirstKey <=
nLowestTimestamp.
I'm planning to make a more substantial API improvement in the future (making
ScanForWalletTransactions private and exposing a higher level rescan method to
RPC code), but Matt Corallo <git@bluematt.me> pointed out this odd behavior
introduced by e2e2f4c "Return errors from importmulti if complete rescans are
not successful" yesterday, so I'm following up now to get rid of badness
introduced by that merge.
Warnings introduced by commit e2e2f4c "Return errors from importmulti if
complete rescans are not successful" and reported by Pavel Janík
<Pavel@Janik.cz> in https://github.com/bitcoin/bitcoin/pull/9773 and
https://github.com/bitcoin/bitcoin/pull/9827
wallet/test/wallet_tests.cpp: In member function ‘void wallet_tests::rescan::test_method()’:
wallet/test/wallet_tests.cpp:377:17: warning: declaration of ‘wallet’ shadows a global declaration [-Wshadow]
CWallet wallet;
This reverts PR #4906, "Coinselection prunes extraneous inputs from
ApproximateBestSubset".
Apparently the previous behavior of slightly over-estimating the set of
inputs was useful in cleaning up UTXOs.
See also #7664, #7657, as well as 2016-07-01 discussion on #bitcoin-core-dev IRC.
Jianping Wu