with an encyrpted wallet my client (0.8.1 compiled myself) crashes, if the walletpassphrase timeout occurs before the keypoolrefill has finished. It just closes, no error/crash log messages. The last line in the log is one of these:
keypool added key 100, size=100
to reproduce do bitcoind walletpassphrase pass 10 && bitcoind keypoolrefill on a machine with no cpu cycles to spare at the moment
Interesting find, guess no one ever thought about such a corner case then.
I meet the same bug.
Bitcoin version v0.8.1-beta (2013-03-17 15:35:36 -0400)
FWIW, I also saw this on my 2aa462e-based next-test, after about 800 keys (targetting 10,000 keys). Initially, I assumed it was relayed to the wallet closing timeout, so when I restarted, I put an effectively-infinite timeout on it; it crashed again after about 800 keys. The third try completed successfully. (Obviously next-test isn't going to be a very good report for this kind of bug, but considering others have similar problems I thought it might be useful info to add)
After upgrade to v0.8.3-beta, the bug still exists.
I use gdb debugļ¼ terminate called after throwing an instance of 'std::runtime_error' what(): CWallet::GenerateNewKey() : AddKey failed
Can you try again with current master?
I tried keypoolrefill 10000 and used walletpassphrase pass 10, which resulted in:
Output in debug window - RPC console (Bitcoin-Qt):
<pre> 11:52:32 keypoolrefill 10000 11:52:34 CWallet::GenerateNewKey() : AddKey failed (code -1) </pre>
No crash for me!
I can confirm that this bug still exists on 0.8.5
Is this still a problem with current master?
I have this issue, on Windows with v0.9.1.0-g026a939-beta (64-bit). Luckily dumpprivkey works but it's still annoying. How can I help?
This wallet was on an installation I seldom use and therefore very simple (1 transaction, 1 bitcoin core upgrade). I still have the old wallet, can I help with some diagnostics?
@bobjansen so can you reproduce this arbitrarily? how do you do that? does it depend on the specific wallet?
@laanwj It seems to depend on this specific wallet. I'm not sure how it got in this state. This is what happens when I use the faulty wallet:
Alternatively, I can do steps 1 to 3 and run keypoolrefill 100 from the console. This gives an error but at least doesn't crash:
Closing also gives the same problem and an extra error message which might be useful:
Something to note: the wallet is not encrypted. As this wallet was only used for this one transaction and I could move the coins elsewhere using my wallet created from the privkey. Therefore I can safely publish the broken wallet for analysis if so desired.
Thanks for the offer, but I don't have time to dive deep into berkeleydb specifics.
For anyone else coming to this issue, what may work is to run with the option -salvagewallet. This dumps the underlying database structure and rebuilds the wallet. Do make sure that you back up your wallet first, as with any every recovery tool) it may make things worse as well.