Assertion failure during rescan

GSPP commented at 3:28 pm on March 8, 2018: none

I’m getting this when rescanning an old wallet:

I clicked ignore and rescanning continued. Eventually the GUI opened. When trying dumpwallet a “runaway exception” caused Bitcoin Core to exit. This is v16.0.

How would we go about addressing this? I cannot send the wallet file since it contains funds.

debug.log:

2018-03-08 13:55:01 Still rescanning. At block 459430. Progress=0.677853 2018-03-08 13:55:58 AddToWalletIfInvolvingMe: Detected a used keypool key, mark all keypool key up to this key as used 2018-03-08 14:12:33 AddToWalletIfInvolvingMe: Topping up keypool failed (locked wallet) 2018-03-08 14:12:33 AddToWallet 2ed2b7d31cffc4af33a0cc44cbaed4b669dcd4849200456e81ce8d0350b20a61 new 2018-03-08 14:12:33 Potential stale tip detected, will try using extra outbound peer (last tip update: 9016 seconds ago) 2018-03-08 14:12:33 Still rescanning. At block 460132. Progress=0.681957 2018-03-08 14:13:19 Potential stale tip detected, will try using extra outbound peer (last tip update: 9834 seconds ago) 2018-03-08 14:13:33 Still rescanning. At block 461005. Progress=0.687196 … 2018-03-08 15:14:48 rescan 13546939ms 2018-03-08 15:14:48 setKeyPool.size() = 98 2018-03-08 15:14:48 mapWallet.size() = 65 2018-03-08 15:14:48 mapAddressBook.size() = 4 2018-03-08 15:14:48 mapBlockIndex.size() = 512418 2018-03-08 15:14:48 nBestHeight = 512304 2018-03-08 15:14:48 torcontrol thread start 2018-03-08 15:14:48 init message: Loading P2P addresses… 2018-03-08 15:14:49 Loaded 64280 addresses from peers.dat 796ms 2018-03-08 15:14:49 init message: Loading banlist… 2018-03-08 15:14:49 init message: Starting network threads… 2018-03-08 15:14:49 net thread start 2018-03-08 15:14:49 addcon thread start 2018-03-08 15:14:49 dnsseed thread start 2018-03-08 15:14:49 init message: Done loading 2018-03-08 15:14:49 opencon thread start 2018-03-08 15:14:49 msghand thread start 2018-03-08 15:14:49 GUI: Platform customization: “windows” 2018-03-08 15:14:49 GUI: PaymentServer::LoadRootCAs: Loaded 31 root certificates 2018-03-08 15:15:00 Loading addresses from DNS seeds (could take a while) 2018-03-08 15:15:00 0 addresses found from DNS seeds 2018-03-08 15:15:00 dnsseed thread exit 2018-03-08 15:15:20 Imported mempool transactions from disk: 290 succeeded, 0 failed, 0 expired, 0 already there 2018-03-08 15:17:39 Potential stale tip detected, will try using extra outbound peer (last tip update: 13694 seconds ago) 2018-03-08 15:23:28 tor: Thread interrupt 2018-03-08 15:23:28 net thread exit 2018-03-08 15:23:28 addcon thread exit 2018-03-08 15:23:28 Shutdown: In progress… 2018-03-08 15:23:28 torcontrol thread exit 2018-03-08 15:23:28 msghand thread exit 2018-03-08 15:23:31 opencon thread exit 2018-03-08 15:23:32 scheduler thread interrupt 2018-03-08 15:23:32 Dumped mempool: 0s to copy, 0.078s to dump 2018-03-08 15:23:32

EXCEPTION: St13runtime_error
CDB: Error -30974, can’t open database wallet.dat
C:\Program Files\Bitcoin\bitcoin-qt.exe in Runaway exception

2018-03-08 15:23:37 CDBEnv::EnvShutdown: Error -30974 shutting down database environment: DB_RUNRECOVERY: Fatal error, run database recovery 2018-03-08 15:24:21

MarcoFalke added the label Wallet on Mar 8, 2018

MarcoFalke added this to the milestone 0.16.1 on Mar 8, 2018

jonasschnelli commented at 4:53 am on March 9, 2018: contributor

Is this reproducible? Does it happens at the same level of progress if you try to rescan again?

GSPP commented at 11:07 am on March 10, 2018: none

Yes it’s reproducible and happens at the same level of progress.

jnewbery commented at 9:13 pm on April 2, 2018: member

This is an assert in MarkReserveKeysAsUsed(), introduced in https://github.com/bitcoin/bitcoin/commit/095142d1f93f39ad2b88dbe8d40140223a1b3900 (#11022)

laanwj removed this from the milestone 0.16.1 on May 17, 2018

laanwj added this to the milestone 0.16.2 on May 17, 2018

jnewbery commented at 9:51 pm on May 24, 2018: member

I’ve dug into this a bit, but I haven’t been able to identify the bug yet.

The first assert is in MarkReserveKeysAsUsed(). This is called by AddToWalletIfInvolvingMe() if a transaction is seen which involves a keypool key in m_pool_key_to_index. MarkReserveKeysAsUsed() asserts that the keypool entry is either in setInternalKeyPool or setExternalKeyPool. This assertion failure indicates that the keypool is in an inconsistent state where a keypool entry isn’t in the external keypool set or the internal keypool set.

I’ve gone through all the places where m_pool_key_to_index, setInternalKeyPool and setExternalKeyPool are updated, and I can’t see anywhere obvious that adds to m_pool_key_to_index without inserting into set{In,Ex}ternalKeyPool (or conversely deletes from set{In,Ex}ternalKeyPool without deleting from m_pool_key_to_index), except if ReserveKeyFromKeyPool() threw one of the std::runtime_errors, caught and continued:

 0        auto it = setKeyPool.begin();
 1        nIndex = *it;
 2        setKeyPool.erase(it);
 3        if (!walletdb.ReadPool(nIndex, keypool)) {
 4            throw std::runtime_error(std::string(__func__) + ": read failed");
 5        }
 6        if (!HaveKey(keypool.vchPubKey.GetID())) {
 7            throw std::runtime_error(std::string(__func__) + ": unknown key in key pool");
 8        }
 9        if (keypool.fInternal != fReturningInternal) {
10            throw std::runtime_error(std::string(__func__) + ": keypool entry misclassified");
11        }
12
13        assert(keypool.vchPubKey.IsValid());
14        m_pool_key_to_index.erase(keypool.vchPubKey.GetID());

Once the assert is hit in MarkReserveKeysAsUsed() and you continued, I wouldn’t be surprised if the wallet’s internal data was corrupted further. @GSPP - a few questions:

have you managed to restore this wallet yet? I suspect trying on V0.15.1 will allow you to dumpwallet
you say this is an ‘old’ wallet. I presume that’s before from V0.15? (ie before the HD wallet split which split the keypool into internal/external)
How large is your debug.log. Are you able to upload the full file somewhere?

GSPP commented at 8:47 am on May 25, 2018: none

I’d be willing to send the wallet to someone on the team. It’s not a very important wallet. When you’re done working on it I’d swipe the funds if there are any.

jnewbery commented at 3:23 pm on May 25, 2018: member

~I’m happy to take a look at the wallet.dat file, with the understanding that I can’t be responsible for any funds in there. I won’t take them, but I can’t be responsible for them :)~

EDIT: On second thoughts, I think this isn’t a great idea. Please don’t send the wallet file to me!

Instead, I recommend you try restoring the wallet in v0.15 and sweep the funds to a new address.

MarcoFalke removed this from the milestone 0.16.2 on May 29, 2018

MarcoFalke added this to the milestone 0.17.0 on May 29, 2018

MarcoFalke removed this from the milestone 0.17.0 on Jul 29, 2018

MarcoFalke added the label Bug on Jul 29, 2018

MarcoFalke closed this on Apr 27, 2020

DrahtBot locked this on Feb 15, 2022

Assertion failure during rescan #12646