EXCEPTION: 22DbRunRecoveryException

schildbach commented at 8:13 pm on February 8, 2012: contributor

$ ~/bitcoin-0.6.0rc1-linux/bin/64/bitcoin-qt

(bitcoin-qt:32391): Gtk-WARNING **: Unable to locate theme engine in module_path: “pixmap”,

EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in Runaway exception

terminate called after throwing an instance of ‘DbRunRecoveryException’ what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery Aborted

schildbach commented at 8:14 pm on February 8, 2012: contributor

Did not find a way to attach a tag. This issue is with 0.6.0rc1.

gavinandresen commented at 7:58 pm on February 14, 2012: contributor

This is a Berkeley DB version mismatch between the last and current version of bitcoin.

Recovery is: make sure bitcoin is not running cd into your .bitcoin directory rm -rf db* database* .lock *.pid

schildbach commented at 2:16 pm on February 15, 2012: contributor

Thanks, that worked.

TheBlueMatt commented at 10:05 pm on February 15, 2012: member

There was no bdb version change between 0.6 and 0.5.X. This is probably just simply a corrupted database.

schildbach commented at 11:05 pm on February 15, 2012: contributor

I don’t believe so. Because bitcoin-qt could still read the old database. And also, then testnet and prodnet databases must have been corrupted at the same time.

TheBlueMatt commented at 11:15 pm on February 15, 2012: member

Unless 0.6 rc1 was built using some non-gitian method, bdb is still the same version that it was 6 months ago (IIRC it was changed in version 0.4). See https://github.com/bitcoin/bitcoin/blame/master/contrib/gitian-descriptors/gitian.yml

schildbach commented at 11:20 pm on February 15, 2012: contributor

When upgrading from 0.4 to 0.5 and then to 0.5.1, I did not encounter this problem. It’s the 0.5.1 to 0.6 RC1 update that reveiled it. As I said, I tested going back to 0.5.1.

TheBlueMatt commented at 11:24 pm on February 15, 2012: member

No users should not have seen a problem going from 0.4 to 0.5.X because of the upgrade (it just means that you cant go back without manually deleting the logs). Your issue is a simple case of log corruption, it happens all the time.

schildbach commented at 11:31 pm on February 15, 2012: contributor

But then again, why is 0.6 RC1 sensitive about a corrupted log and 0.5.1 is not? If the log is corrupt, it should not be readable with any of the two bitcoin-qt versions.

gavinandresen commented at 11:34 pm on February 15, 2012: contributor

I agree with Goonie, given the number of people who’ve run into this issue (including myself with both the testnet and mainnet Faucets) I suspect SOMETHING has changed.

TheBlueMatt commented at 11:37 pm on February 15, 2012: member

Then its a legitimate bug and is being caused by something internal to bitcoin…

gavinandresen commented at 9:52 pm on March 20, 2012: contributor

I’m going to use this comment to keep track of my investigations into this bug. I’m running different versions of Bitcoin in a virtual machine, and seeing what version of BDB they write.

Command to dump out the BDB version:

0od -j12 -N8 -tx4 ~/.bitcoin/testnet/database/log.000*

gives:

00000014 00040988 0000000f
1# 0x040988 is the bdb magic number
2# 0x0f is the version

Results (last hex value on first line is the version):

Bitcoin 0.3.24 : 0x0e (db4.7) Bitcoin 0.4.0 : 0x0f (db4.8) Bitcoin 0.5.3 : 0x0f Bitcoin 0.6.0rc1 : 0x0f Bitcoin 0.6.0rc4 : 0x0f

BUT: If I compile and link on Ubuntu 11.10 64-bit VM: : 0x10 On my mac: : 0x10 … both of which are also bdb 4.8. I’m confused; are there two versions of 4.8 with incompatible log file formats?

schildbach commented at 2:19 pm on April 8, 2012: contributor

My original issue has been fixed in bitcoin-qt 0.6.0 (final).

(I did not manually migrate/fix any databases)

ancow commented at 2:45 pm on April 8, 2012: none

Just out of curiosity, are you using the bitcoin PPA, too? If so, any upgrade that comes from the PPA will work but any downloads from sourceforge won’t because of the version issue Gavin pointed out above. That would also mean that the issue isn’t fixed at all, it just never was in bitcoin but rather in the incompatible BDB v4.8 versions.

schildbach commented at 3:20 pm on April 8, 2012: contributor

@ancow Ah, that’s true. I am using the Ubuntu PPA version.

Diapolo commented at 5:19 pm on April 8, 2012: none

If that’s fixed you can close the issue :).

ancow commented at 7:32 pm on April 8, 2012: none

It’s not fixed; it will happen with all non-PPA versions as soon as the PPA version is installed. IOW, it’ll happen again for the next RC release. It just isn’t really a bug in bitcoin…

meonkeys commented at 6:17 pm on April 30, 2012: none

Is this perhaps the same issue? http://bitcoin.stackexchange.com/questions/3533/error-loading-wallet-dat-wallet-corrupted

Bitcoin 0.4.1 is able to work with everything in my ~/.bitcoin dir. 0.5.4rc3 and 0.6.0 do not work (both report Error loading wallet.dat: Wallet corrupted). Is there some way to safely “upgrade” my wallet (and other stuff in ~/.bitcoin)? I figured this would happen automatically when upgrading bitcoin.

PanderMusubi commented at 3:44 pm on September 17, 2012: none

Bitcoin (0.6.3 on Ubuntu 12.04) should be able to deal with this error nicely and offer proper suggestions to the user.

After removing database and .lock I get the foll0wing error:

0$ bitcoin-qt 
1
2
3************************
4EXCEPTION: 11DbException       
5Db::open: Invalid argument       
6bitcoin in Runaway exception       
7
8bitcoin-qt: /usr/include/boost/thread/pthread/mutex.hpp:50: void boost::mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
9Aborted (core dumped)

What is the workaround for that?

laanwj commented at 2:51 pm on November 4, 2013: member

Issue hasn’t been touched for a year and BDB has been replaced apart from the wallet. Though LevelDB has its own, new issues, we can close this one.

laanwj closed this on Nov 4, 2013

ptschip referenced this in commit c22f25f3ae on Nov 11, 2017

sipa referenced this in commit 6c0259fc2f on Oct 28, 2020

fanquake referenced this in commit bd27ab1f97 on Oct 28, 2020

DrahtBot locked this on Sep 8, 2021

EXCEPTION: 22DbRunRecoveryException #809