getbalance rpc call results in 100% cpu #3903

bitcoind version: v0.9.0rc2-82-g98f4c6c-beta

i haven't been able to run bitcoind getbalance on recent git versions. every time i try to, it results in 100% cpu and i have to kill and restart the daemon eventually. i've let it run for up to 10 minutes that way, but i can't afford to let it lock up my system for any longer than that to see how long it might take to finish, if it ever will. i'm wondering if this is related to #3661. i know my wallet has at least one double spend in it, because i've seen this message in my debug log: ERROR: AcceptToMemoryPool : inputs already spent.

inputs already spent has nothing to do with the wallet.

How many transactions are in this wallet roughly?

6700 unique txs. but i have several thousand addresses and many of the txs involve multiple addresses. if i count the total non-unique txs from the output of listreceivedbyaddress, the number is 400K.

and for comparison, listreceivedbyaddress only took 110 seconds to complete.

I tried to workaround this problem by scripting a solution summing the amounts from listreceivedbyaddress, but the amounts are completely wrong- it's only 10% of the expected amount (which was verified with blockchain.info). listaccounts and listreceivedbyaccount are also reporting the same wrong amounts as well.

So if the address amounts are wrong, the number of transactions I listed above are probably off as well.

I had a similar problem when updating from 0.8.6 to 0.9.0. In my case, getinfo showed the same behaviour as getbalance (100% cpu usage, never completes). Running with -salvagewallet solved that but left me with a fraction of my funds (10% is about right). I worked around it by creating a new wallet, opening the old wallet in 0.6.8 and moving all funds over.

The problem (also noted by @gavinandresen when he made the anti-malleability wallet changes for 0.9.0) is that we don't have any really busy wallets to test with.

We would need such a wallet in the dev team to be able to profile / debug / optimize this.

If someone experiencing an extreme case of this problem (e.g. taking a minute or more) is able to build Bitcoin core for themselves and test the simple patch in pull #3973 it would be helpful. I'm not sure if it is the same problem here or not, but I think it may be.

Tested the patch and it works for me.

BugAndNewsReporter: Can I understand that to mean that it made it much faster?

Yes, getbalance now returns with the same speed as 0.8.6. So I'd consider this issue solved.