This sets up a vs developer command prompt and should hopefully should
be more resilient to upstream changes
Co-authored-by: David Gumberg <davidzgumberg@gmail.com>
Github-Pull: #32513
Rebased-From: e1a1b14c9359751a4d0117a27a303d1f1d3ed30f
We can use vswhere.exe directly to create a vs developer
prompt and so can remove this third party dependency.
Co-authored-by: David Gumberg <davidzgumberg@gmail.com>
Github-Pull: #32513
Rebased-From: 7ae0497eef8f5b37fc1184897a5bbc9f023dfa67
removeprunedfunds removes all entries from mapTxSpends for the
inputs of the pruned tx. However, this is incorrect, because there could be
multiple entries from conflicting transactions (that shouldn't be
removed as well). This could lead to the wallet creating invalid
transactions, trying to double spend utxos.
The bug persists when the conflicting tx was mined, because
the wallet trusts its internal accounting instead of calling
AddToSpends again.
Github-Pull: #34358
Rebased-From: 1f60ca360eb83fa7982b1aac402eaaf477294197
The -ffile-prefix-map option is no longer used and it seems fine to
remove the warning about it possibly breaking coverage builds.
If this needs documentation, the dev notes seem like a better place,
because it also affects other places, such as depends. C.f. commit
407062f2ac93624f350e9e8a4f641c882a2aaf2f
Github-Pull: #34413
Rebased-From: fa2e1b85dd6b263a77294566bd361d7873731045
The section claims to be for ccache builds, however those are already
fixed after commit 1cc58d3a0c653ac30df04d1010a3cf84c6bc307a.
If there are still any build or debug problems after that commit,
dedicated instructions can be added back, along with exact steps to
reproduce and test.
Github-Pull: #34413
Rebased-From: fa06cd4ba7303bd3036467cf00d12f36c94bcaff
Facilitate use on distros that might have 'tar' as something else, such
as 'gtar', i.e Chimera.
Github-Pull: #34390
Rebased-From: be2b48b9f3e56b672e391e18a09f2d5f4e78d74e
The regex `(.*)` was capturing `\r` from subprocess output on Windows,
causing the closing parenthesis in logs to wrap to the next line.
Stripping whitespace from the regex match fixes the formatting.
Github-Pull: #34282
Rebased-From: 979d41bfab248990d7d520873d17fe52daa8d402
The previous `assert` used `>=`, allowing `input_index == psbt.inputs.size()` and out-of-bounds access in `psbt.inputs[input_index]`.
Found during review: https://github.com/bitcoin/bitcoin/pull/31650#discussion_r2685892867
Github-Pull: #34272
Rebased-From: 2f5b1c5f80590ffa6b5a5bcfb21fddb1dc22e852
Refactor a common way to perform the failed migration test that exists
for default wallets, and add relative-path wallets and absolute-path
wallets.
Github-Pull: #34226
Rebased-From: eeaf28dbe0e09819ab0e95bb7762b29536bdeef6
The test calls migrate_and_get_rpc(), which sets mock time internally.
The caller caches a mock time value and later relies on it to predict the
backup filename, so setting the mock time again could cause a naming
mismatch.
Fix this by calling the migration RPC directly. Since the test expects the
migration to fail, migrate_and_get_rpc() is unnecessary here.
Github-Pull: #34221
Rebased-From: cbf0bd35bbf312f3b13d92d281d7112e4b43b9c3
Because the default wallet has no name, the watch-only and solvables
wallets created during migration end up having no name either.
This fixes it by applying the same prefix name we use for the backup
file for an unnamed default wallet.
Before: watch-only wallet named "_watchonly"
After: watch-only wallet named "default_wallet_watchonly"
Github-Pull: #34156
Rebased-From: 82caa8193a3e36f248dcc949e0cd41def191efac
Right now, after migration the last message users see is "migration completed",
but the migration isn't actually finished yet. We still need to load the new wallets
to ensure consistency, and if that fails, the migration will be rolled back. This
can be confusing for users.
This change logs the post-migration loading step and if a wallet fails to load and
the migration will be rolled back.
Github-Pull: #34156
Rebased-From: d70b159c42008ac3b63d1c43d99d4f1316d2f1ef
The first test verifies that restoring into an existing empty directory
or a directory with no .dat db files succeeds, while restoring into a
dir with a .dat file fails.
The second test covers restoring into the default unnamed wallet
(wallet.dat), which also implicitly exercises the recovery path used
after a failed migration.
The third test covers failure during restore on a prune node. When
the wallet last sync was beyond the pruning height.
Github-Pull: #34156
Rebased-From: f011e0f0680a8c39988ae57dae57eb86e92dd449
Verifies that a failed migration of the unnamed (default) wallet
does not erase the main /wallets/ directory, and also that the
backup file exists.
Github-Pull: #34156
Rebased-From: 36093bde63286e19821a9e62cdff1712b6245dc7
When migrating any legacy unnamed wallet, a failed migration would
cause the cleanup logic to remove its parent directory. Since this
type of legacy wallet lives directly in the main '/wallets/' folder,
this resulted in unintentionally erasing all wallets, including the
backup file.
To be fully safe, we will no longer call `fs::remove_all`. Instead,
we only erase the individual db files we have created, leaving
everything else intact. The created wallets parent directories are
erased only if they are empty.
As part of this last change, `RestoreWallet` was modified to allow
an existing directory as the destination, since we no longer remove
the original wallet directory (we only remove the files we created
inside it). This also fixes the restore of top-level default wallets
during failures, which were failing due to the directory existence
check that always returns true for the /wallets/ directory.
This bug started after:
f6ee59b6e2
Previously, the `fs::copy_file` call was failing for top-level wallets,
which prevented the `fs::remove_all` call from being reached.
Github-Pull: #34156
Rebased-From: f4c7e28e80bf9af50b03a770b641fd309a801589
Track what RestoreWallet creates so only those files and directories
are removed during a failure and nothing else. Preexisting paths
must be left untouched.
Note:
Using fs::remove_all() instead of fs::remove() in RestoreWallet does
not cause any problems currently, but the change is necessary for the
next commit which extends RestoreWallet to work with existing directories,
which may contain files that must not be deleted.
Github-Pull: #34156
Rebased-From: 4ed0693a3f2a427ef9e7ad016930ec29fa244995
Signal m_tip_block_cv when Ctrl-C is pressed or SIGTERM is received, the same
way it is currently signalled when the `stop` RPC is called. This lets RPC
calls like `waitforblockheight` and IPC calls like `waitTipChanged` be
interrupted, instead of waiting for their original timeouts and delaying
shutdown.
Historical notes:
- The behavior where `stop` RPC signals `m_tip_block_cv`, but CTRL-C does not,
has been around since the condition variable was introduced in #30409
(7eccdaf16081d6f624c4dc21df75b0474e049d2b).
- The signaling was later moved without changing behavior in #30967
(5ca28ef28bcca1775ff49921fc2528d9439b71ab). This commit moves it again to
the Interrupt() function, which is probably the place it should have been
added initially, so it works for Ctrl-C shutdowns as well as `stop`
shutdowns.
- A Qt shutdown bug calling wait methods was fixed previously in #18452
(da73f1513a637a9f347b64de66564d6cdb2541f8), and this change updates that
fix to avoid the hang happening again in Qt.
Github-Pull: #33511
Rebased-From: c25a5e670b27d3b6eb958ce437dbe89678bd1511
Currently when CTRL-C is pressed and there is an active `waitforblockheight`,
or `waitforblock`, or `waitfornewblock` RPC call, or a mining interface
`waitTipChanged` IPC call with a long timeout, the node will not shut down
right away, and will wait for the timeout to be reached before exiting.
This behavior is not ideal and only happens when the node is stopped with
CTRL-C or SIGTERM. When the node is stopped with `bitcoin-cli stop`, the wait
calls are interrupted and the node does shut down right away.
The next commit improves node behavior. This commit just adds test coverage to
simplify the next commit and clarify the change in behavior there.
Github-Pull: #33511
Rebased-From: 6a29f79006a9d60b476893dface5eea8f9bf271c
