Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encrypted wallets and -salvagewallet #2480

Closed
laanwj opened this issue Apr 7, 2013 · 8 comments
Closed

Encrypted wallets and -salvagewallet #2480

laanwj opened this issue Apr 7, 2013 · 8 comments
Labels
Milestone

Comments

@laanwj
Copy link
Member

laanwj commented Apr 7, 2013

Salvaging an encrypted wallet makes bitcoin quit with the following error:

bitcoin-qt: /usr/include/boost/thread/pthread/pthread_mutex_scoped_lock.hpp:26: boost::pthread::pthread_mutex_scoped_lock::pthread_mutex_scoped_lock(pthread_mutex_t*): Assertion `!pthread_mutex_lock(m)' failed.
Aborted (core dumped)

Steps to reproduce:

  1. Create new testnet wallet
  2. Encrypt with a passphrase
  3. Run with -salvagewallet

debug.log:

init message: Verifying wallet...
dbenv.open LogDir=/home/.../.bitcoin/testnet3/database ErrorFile=/home/.../.bitcoin/testnet3/db.log
Renamed wallet.dat to wallet.1365321353.bak
Salvage(aggressive) found 317 records
Bound to [::]:18333
Bound to 0.0.0.0:18333
init message: Loading block index...
Opening LevelDB in /home/.../.bitcoin/testnet3/blocks/index
Opened LevelDB successfully
Opening LevelDB in /home/.../.bitcoin/testnet3/chainstate
Opened LevelDB successfully
LoadBlockIndexDB(): last block file = 0
LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=65142, size=47761205, heights=0...65141, time=2011-02-02...2013-04-07)
LoadBlockIndexDB(): transaction index disabled
LoadBlockIndexDB(): hashBestChain=000000000a00a2818dd027f323048e7e0b273a3cd0511b0ad129166d9d5d45a2  height=65141 date=2013-04-07 07:46:02
init message: Verifying blocks...
Verifying last 288 blocks at level 3
No coin database inconsistencies in last 289 blocks (3282 transactions)
 block index            1377ms
init message: Loading wallet...
nFileVersion = 80000
Performing wallet upgrade to 60000
Cannot initialize keypool

The keypool error appears every time at startup, from then on. The wallet may be corrupted, but it from the error appears to be a bug in the code with mutexes.

@ghost
Copy link

ghost commented Apr 16, 2013

This is your fix. You can't trail like that in Boost(yet): http://stackoverflow.com/questions/11505811/creating-a-separate-boost-thread-for-endpoint-listen-in-a-multithreaded-progra

Sorry i'm not at my workstation to test but I have had that issue before and those directions fixed it

@sipa
Copy link
Member

sipa commented Apr 25, 2013

There are two issues here. The first is the reported problem (-salvagewallet not working with encrypted wallets due the the keypool initialization failing, see #2566 for a fix). The other seems a problem with exceptional exits in combination with Gavin's thread rewrite in Bitcoin-Qt.

@gavinandresen
Copy link
Contributor

I'm testing a fix for the second issue; it is being caused by destructors being called after main() exits.

gavinandresen added a commit to gavinandresen/bitcoin-git that referenced this issue May 2, 2013
Bitcoin-Qt could core dump if application initialization failed in certain ways.

I double-fixed this:
1) qt/bitcoin.cpp now shuts down core threads cleanly if AppInit2 returns false
2) init.cpp now exits before StartNode() if strErrors is set (no reason to StartNode if we're just going to exit immediately anyway).

Tested by triggering all of the various ways AppInit2 can fail, either by passing bogus command-line arguments or just recompiling tweaked code to simulate failure.

This is a partial fix for bitcoin#2480
sipa pushed a commit to sipa/bitcoin that referenced this issue May 2, 2013
Bitcoin-Qt could core dump if application initialization failed in certain ways.

I double-fixed this:
1) qt/bitcoin.cpp now shuts down core threads cleanly if AppInit2 returns false
2) init.cpp now exits before StartNode() if strErrors is set (no reason to StartNode if we're just going to exit immediately anyway).

Tested by triggering all of the various ways AppInit2 can fail, either by passing bogus command-line arguments or just recompiling tweaked code to simulate failure.

This is a partial fix for bitcoin#2480
@laanwj
Copy link
Member Author

laanwj commented May 3, 2013

Can confirm that this is solved by #2566

@laanwj laanwj closed this as completed May 3, 2013
@ghost
Copy link

ghost commented May 6, 2013

Sipa, you have 0.010945 BTC waiting for you on bitcoinbounties.com. Please login with your Github account and provide a payout Bitcoin address so we can send it to you.

Thanks! :-)

@sipa
Copy link
Member

sipa commented May 7, 2013

@ryepdx Great, but the "Complete registration" button after entering my address doesn't really seem to do anything...

@ghost
Copy link

ghost commented May 7, 2013

Hmm, okay. What browser are you in? Can you email me at (redacted)? I don't want to spam up this issue page.

EDIT: Looks like Github started requiring a User-Agent string in their API calls. Updated the Github API library I was using and everything seems to be working now. How does it look on your end?

laudney pushed a commit to reddcoin-project/reddcoin-3.10 that referenced this issue Mar 19, 2014
Bitcoin-Qt could core dump if application initialization failed in certain ways.

I double-fixed this:
1) qt/bitcoin.cpp now shuts down core threads cleanly if AppInit2 returns false
2) init.cpp now exits before StartNode() if strErrors is set (no reason to StartNode if we're just going to exit immediately anyway).

Tested by triggering all of the various ways AppInit2 can fail, either by passing bogus command-line arguments or just recompiling tweaked code to simulate failure.

This is a partial fix for bitcoin#2480
@webwakko
Copy link

webwakko commented Dec 7, 2017

How can you open a *.bak file created by --salvagewallet?

@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
Projects
None yet
Development

No branches or pull requests

4 participants