Skip to content

Conversation

@gavinandresen
Copy link
Contributor

Compiling with -DDEBUG_LOCKORDER and running the qa/rpc-test/ regression
tests uncovered a couple of wallet methods that should (but didn't)
acquire the cs_wallet mutext.

I also changed the AssertLockHeld() routine print to stderr and
abort, instead of printing to debug.log and then assert()'ing.
It is annoying to look in debug.log to find out which
AssertLockHeld is failing.

Compiling with -DDEBUG_LOCKORDER and running the qa/rpc-test/ regression
tests uncovered a couple of wallet methods that should (but didn't)
acquire the cs_wallet mutext.

I also changed the AssertLockHeld() routine print to stderr and
abort, instead of printing to debug.log and then assert()'ing.
It is annoying to look in debug.log to find out which
AssertLockHeld is failing.
@BitcoinPullTester
Copy link

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/ca4cf5cff6fb60c9769b62acce2e3a8fcd0e7aae for binaries and test log.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never known the specific reason why some methods in CWallet acquire the lock and others such as address book manipulation do not (and assume the caller already holds it). But it's always been that way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally cs_wallet and mapWallet would be private members, and all methods would acquire the lock themselves. But ideally we'd completely rewrite the wallet with deterministic key support, multisig/off-device-signing support, etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not speaking about ideally, just about the way things are implemented now :) Will it have effect in any of the caller sites that the locking behavior of SetAddressBook changed? After all the caller sites (if they're correct) already acquire the locks. I recently fixed some UI functions that forgot to acquire the wallet lock (28352af). I suppose this is not an issue due to the use of recursive mutexes so it doesn't matter that it acquires/releases another instance of the lock.

@gavinandresen
Copy link
Contributor Author

Merging, because I keep tripping myself up testing other patches without this.

RE: locks held by caller: indeed, recursive mutexes mean if callers hold the wallet lock, all will be OK.

gavinandresen added a commit that referenced this pull request Feb 24, 2014
Wallet locking fixes for -DDEBUG_LOCKORDER
@gavinandresen gavinandresen merged commit a16ad1c into bitcoin:master Feb 24, 2014
@gavinandresen gavinandresen deleted the wallet_lock_fixes branch March 13, 2014 16:34
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants