0.16.0 bitcoin-qt: "Assertion `copyFrom' failed" during launch

[DeltaLeonis]

During startup of bitcoint-qt version 0.16.0

$ ./bitcoin-qt

the following assertion is triggered:

bitcoin-qt: wallet/wallet.cpp:542: void CWallet::SyncMetaData(std::pair<std::_Rb_tree_iterator<std::pair<const COutPoint, uint256> >, std::_Rb_tree_iterator<std::pair<const COutPoint, uint256> > >): Assertion `copyFrom' failed.

The issue reliably reproduces with 0.16.0 when using the same ~/.bitcoin directory that was used without problems in 0.15.1. Relaunching 0.15.1 instead of 0.16.0 gives no assertion failure and still works without any issue.

A (stripped down) debug.log is attached here. The log really ends at 2018-04-28 17:21:47 init message: Loading wallet... (which seems consistent with the assertion failure).

bitcoin.conf is an empty, zero byte file.

This machine runs (K)Ubuntu 17.04. CPU is an AMD A6-7400K Radeon R5, 6 Compute Cores 2C+4G. Disk is an Intel 512 GB 545s SSD.

Bitcoin Core 0.15.1 was downloaded from https://bitcoin.org/bin/bitcoin-core-0.15.1/bitcoin-0.15.1-x86_64-linux-gnu.tar.gz if I recall correctly.

Bitcoin Core 0.16.0 was downloaded from https://bitcoincore.org/bin/bitcoin-core-0.16.0/bitcoin-0.16.0-x86_64-linux-gnu.tar.gz.

Note that those are not versions from the Ubuntu repositories/the Ubuntu specific downloads.

[laanwj]

Interesting: this assertion was added in #11074. This was indeed first released in 0.16.0.

Can you try to run with that commit (6c4042a) reverted?

It might segfault later on, I have no idea what can cause copyFrom to be null but apparently the assumption behind adding it was not correct.

[maflcko]

We should probably return early if there is nothing to copy from, i.e. range.first == range.second

[DeltaLeonis]

Thanks for the response. I will try to (build and) run 0.16.0 with commit 6c4042a reverted but having limited time available at the moment it might take a while before I follow up.

[DeltaLeonis]

With commit 6c4042a reverted I get:

bitcoin-qt: wallet/wallet.cpp:547: void CWallet::SyncMetaData(std::pair<std::_Rb_tree_iterator<std::pair<const COutPoint, uint256> >, std::_Rb_tree_iterator<std::pair<const COutPoint, uint256> > >): Assertion `copyFrom && "Oldest wallet transaction in range assumed to have been found."' failed.

I could try with commit fdc3293 additionally reverted but it seems obvious at this point that it would dereference a NULL pointer at

if (!copyFrom->IsEquivalentTo(*copyTo)) continue;

[laanwj]

This should work:

diff --git a/src/wallet/wallet.cpp b/src/wallet/wallet.cpp
index 6e0f49f..844167d 100644
--- a/src/wallet/wallet.cpp
+++ b/src/wallet/wallet.cpp
@@ -548,7 +548,9 @@ void CWallet::SyncMetaData(std::pair<TxSpends::iterator, TxSpends::iterator> ran
         }
     }
 
-    assert(copyFrom);
+    if (!copyFrom) {
+        return;
+    }
 
     // Now copy data from copyFrom to rest:
     for (TxSpends::iterator it = range.first; it != range.second; ++it)

[DeltaLeonis]

This does indeed seem to work.

However, I guess it only fixes the symptom but does not explain why copyFrom is a nullptr for me, yet isn't for most people? (well... that's what I assume).

I have not tried to understand the code in more detail and/or run with GDB, but can try to do so if we want to understand the cause? Two remarks about this wallet:

• It only consists of a few old transactions (over 300 000 confirmations) where coins were received
• No coins were ever spent
• It's not an HD wallet

By the way, note that the line

assert(copyFrom && "Oldest wallet transaction in range assumed to have been found.");

seems superfluous to me anyway (either the assert(copyFrom) or your suggested patch will prevent it from ever failing).

[laanwj]

I think the explanation is simply that in your case, there is no metadata to sync, so the range is empty.