zcash: Not an actual locking fix; just eliminates unnecessary recursive
zcash: locking (which is a long-term goal).
zcash: cherry picked from commit 1beea7af92994dca83facb11bbef82b24b538400
zcash: https://github.com/bitcoin/bitcoin/pull/12333
This resolves an issue where getrawmempool() can race mempool
notification signals. Intuitively we use mempool.cs as a "read
lock" on the mempool with cs_main being the write lock, so holding
the read lock intermittently while doing write operations is
somewhat strange.
This also avoids the introduction of cs_main in getrawmempool()
which reviewers objected to in the previous fix in #12273
zcash: cherry picked from commit 85aa8398f5d13c659299b81cdae377462b4f8316
zcash: https://github.com/bitcoin/bitcoin/pull/12368
The HTTP worker thread counter, as well as the RAII object that was used
to maintain it, is unused now, so can be removed.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
zcash: cherry picked from commit 11e01515fe0fbc7823d4111ad6e016a02c485a78
zcash: https://github.com/bitcoin/bitcoin/pull/12366
This function, which waits for all threads to exit, is no longer needed
now that threads are joined instead.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
zcash: cherry picked from commit f94665466ed50e868c98b1a1c708ad5767727bb6
zcash: https://github.com/bitcoin/bitcoin/pull/12366
This prevents a potential race condition if control flow ends up in
`ShutdownHTTPServer` before the thread gets to `queue->Run()`,
deleting the work queue while workers are still going to use it.
Meant to fix#12362.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
zcash: cherry picked from commit b1c2370dde9ade180c638e5d9a4797f085322b5b
zcash: https://github.com/bitcoin/bitcoin/pull/12366
The bug was introduced in 2.1.6-beta, versions before that don't need the
workaround.
zcash: currently, we build with libevent-2.1.12, so this fix is needed
zcash: cherry picked from commit 97932cd2689659addfbb58dc6148928b73af3bd0
zcash: https://github.com/bitcoin/bitcoin/pull/11593
A rare race condition may trigger while awaiting the body of a message, see
upsteam commit 5ff8eb26371c4dc56f384b2de35bea2d87814779 for details.
This may fix some reported rpc hangs/crashes.
zcash: currently, we build with libevent-2.1.12, so this fix is needed
zcash: cherry picked from commit 6b58360f9b64eb0b680a662fdfd590e47f115f44
zcash: https://github.com/bitcoin/bitcoin/pull/11593
Issue: #10905
By returning the result, a few useless lines can be removed.
Return-value-optimization means there should be no copy.
zcash: cherry picked from commit 5cb3da04b8882ca975b4e3d6c089c64bbaf67d0d
zcash: https://github.com/bitcoin/bitcoin/pull/10916
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/
zcash: cherry picked from commit de9a1db2ed14e0c75ffd82dc031f7ad30c56d195
zcash: https://github.com/bitcoin/bitcoin/pull/11126
Update libsecp256k1 subtree
The first subtree merge brings us to the same commit as upstream (bitcoin/bitcoin#20257).
The second subtree merged brings us to current master, which includes most of our local changes.
After this, our remaining local changes are:
- 75f9f8f95b (the change to `secp256k1_scalar_get_b32`)
- e917cb614f (compile with C99)
Link with ntdll library on Windows
This fixes a regression for builds targeting Windows introduced in #4947. It also includes a minor cleanup to fix a build warning.
closes#5051
This fixes#5051, which is a regression caused by the dependency on the ntapi crate
(via mio, via tokio) added by #4947.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Bitcoin Core doesn't actually use tags for managing versions of their
forked dependencies, so we should separately rework this logic for all
of the subtree-managed dependencies. But this at least prevents false
positives.
Bitcoin 0.15 locking PRs
These are locking changes from upstream (bitcoin core) release 0.15, oldest to newest (when merged to the master branch).
Each commit also includes a reference both to the PR and the upstream commit.
- bitcoin/bitcoin#9497
Bitcoin 0.14 locking PRs
These are locking changes from upstream (bitcoin core) release 0.14, oldest to newest (when merged to the master branch).
Each commit also includes a reference both to the PR and the upstream commit.
- bitcoin/bitcoin#8472
- bitcoin/bitcoin#8606
- Excludes a lock move because we don't have bitcoin/bitcoin#7840 which this move was partially-reverting.
- bitcoin/bitcoin#9230
- Only first commit (we don't have `LogTimestampStr` anymore).
- bitcoin/bitcoin#9243
- Only the sixth commit, excluding `IsArgSet` locking (we haven't pulled that function in yet).
- bitcoin/bitcoin#9626
- The cherry-picked commit does not match the upstream at all, but the resulting lock is useful.
- bitcoin/bitcoin#9679
- bitcoin/bitcoin#9227
- bitcoin/bitcoin#9698
- Excludes change to `CConnman::PushMessage` in second commit (which we don't have yet).
- bitcoin/bitcoin#9708
- bitcoin/bitcoin#9771
A new AssertLockHeld(cs_wallet) call was added in commit a58370e
"Dedup nTimeFirstKey update logic" (part of PR #9108).
The lock held assertion will fail when loading prexisting wallets files from
before the #9108 merge that have watch-only keys.
zcash: cherry picked from commit 07afcd6379bb46ace5856f6a47a9188cf9aed2ea
zcash: https://github.com/bitcoin/bitcoin/pull/9771
These are (afaik) all long-standing races or concurrent accesses. Going
forward, we can clean these up so that they're not all individual atomic
accesses.
- Reintroduce cs_vRecv to guard receive-specific vars
- Lock vRecv/vSend for CNodeStats
- Make some vars atomic.
- Only set the connection time in CNode's constructor so that it doesn't change
zcash: cherry picked from commit 321d0fc6b6624c65508f8b9059418cb936f0bbbe
zcash: https://github.com/bitcoin/bitcoin/pull/9708
João Barbosa
Matt Corallo
Wladimir J. van der Laan
practicalswift
Cory Fields
MeshCollider
Marko Bencun
Russell Yanofsky
Homu
Jack Grigg
Daira Hopwood
Kris Nuttycombe
Jeremy Rubin