GetWalletTx
and IsMine
overloads.
GetWalletTx
and IsMine
overloads.
36@@ -37,6 +37,7 @@ namespace {
37 //! Construct wallet tx struct.
38 WalletTx MakeWalletTx(CWallet& wallet, const CWalletTx& wtx)
39 {
40+ LOCK(wallet.cs_wallet);
IsMine
is called for each input and output.
I’d say refactor. Only change in behavior is that now some races aren’t possible, for instance, some import against MakeWalletTx
. But I don’t see these as bugfix.
Edit: well, without this change, if some transaction has multiple inputs/outputs for the same key, and this key is imported concurrently to MakeWalletTx
, then the resulting WalletTx
can be wrong. But this is very unlikely I think.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
1598@@ -1597,6 +1599,7 @@ void CWalletTx::GetAmounts(std::list<COutputEntry>& listReceived,
1599 nFee = nDebit - nValueOut;
1600 }
1601
1602+ LOCK(pwallet->cs_wallet);
In commit “wallet: IsMine overloads require cs_wallet lock” (d8441f30ff57e4ae98cff6694c995eaffc19c51a)
Maybe with this expanded lock scope. EXCLUSIVE_LOCKS_REQUIRED(cs_wallet) could be added to IsChange(), and that method wouldn’t need to lock cs_wallet recursively. Not sure how much extra work that is, however, so maybe it is a suggestion for a followup
IsChange
and GetChange
only.
1982@@ -1983,6 +1983,7 @@ bool CWalletTx::IsTrusted(std::set<uint256>& trusted_parents) const
1983 if (!InMempool()) return false;
1984
1985 // Trusted if all inputs are from us and are in the mempool:
1986+ LOCK(pwallet->cs_wallet);
In commit “wallet: GetWalletTx requires cs_wallet lock” (a13cafc6c6998baedf3c5766259c21fcd763b99e)
Adding a lock here doesn’t seem like the best thing because this is a recursive function. So code above can run unlocked during the base call but locked during recursive calls, which is confusing and could make it harder to detect bugs.
Maybe instead of locking here, IsTrusted could get an EXCLUSIVE_LOCKS_REQUIRED(cs_wallet) annotation. It seems like IsTrusted is only called a few places, and with cs_wallet already locked, so it wouldn’t be a big change.