Coin selection temporarily unresponsive #6338

While bitcoin-qt is downloading the chain to synchronize with the network, opening the coin control dialog box makes the GUI unresponse with no notification to the user on what is occuring. This is duplicatable behavior for me, and gui lockup time varied from as high as a minute to as low as 8 second. As soon as the blockchain is syncronized, no gui lockup occurs.

Step 1: Open up a Bitcoin Core wallet that is behind on synchronization. Mine was behind about 48 hours, giving me a few minutes to test before synchronization was complete.

Step 2: Go to the Send tab, and in the Coin Control Features box click 'Inputs...'. The app will no become unresponsive for roughly 30 seconds and after some time the coin selection dialog will eventually appear.

Step 3: Try to reproduce after blockchain is fully syncronized. Notice that no more delay is occurring.

Verified on Bitcoin Core version v0.10.1 (64-bit) linux.

Theory: Verifying incoming blocks is taking a lot of CPU. Pulling up the Coin Selection dialog may also take some CPU to construct the Tree of Transactions. (My wallet was very small with only a few entries, but non the less my gui was still locking up.) Perhaps the app can prioritize building the Coin Selection window for the user over any background processes that are verifying blocks. The Background block verifying should be a lower priority background thread, though i admit I know little about how threading works or if this is what is actually causing the issue.

This is likely something locking cs_main. That sounds about like the current issue that slows down message processing while ActivateBestChain() is being run with lots of blocks to connect.

You could verify that by tailing the log and watching when the gui is frozen. I bet you'll see a stream of "UpdateTip: new best=", then unfrozen gui the instant that's done.

I sent a transaction yesterday that took the two addresses I had in my wallet. Now my wallet is empty, and I for the moment I can no longer reproduce the issue.

I have added funds to my wallet, but currently am not able to duplicate the issue. I believe this means the issue was in creation of the tree in the coin selection dialog for the specific transactions I previously held.

I was able to duplicate it again now. Response times aren't as long as they were before, but still getting delays of around 8 seconds which is substantial and is probably the same issue I originally reported.

With -debug -printtoconsole, ...

when I am seeing these msgs, the 'Inputs...' button response just fine, no issue.

got inv: tx a79c3767db0e08c8fd2f25f3d35dd0d526631c42d5fa199a1b639b8f35d27b69 have peer=7 received: inv (37 bytes) peer=9 got inv: tx c3df9219382981d3ea4126e42af99c7079a213c9f93551cb16c2fdd758afedca new peer=9 askfor tx c3df9219382981d3ea4126e42af99c7079a213c9f93551cb16c2fdd758afedca 0 (00:00:00) peer=9 Requesting tx c3df9219382981d3ea4126e42af99c7079a213c9f93551cb16c2fdd758afedca peer=9 sending: getdata (37 bytes) peer=9 received: inv (37 bytes) peer=11

On the other hand, when these msgs are coming up, the 'Inputs...' button is not responding and bitcoin-qt is unresponsive.

estimates: for confirming within 0 blocks based on 100/100 samples, fee=0.00077821 BTC/kB, prio=1.6705e+10 ... estimates: for confirming within 24 blocks based on 100/100 samples, fee=0.00001004 BTC/kB, prio=6.13641e+07 UpdateTip: new best=00000000000000000a8fd8b725a30bcabfda90b864d112303dd14d60b1d64501 height=362758 log2_work=82.995042 tx=73548426 date=2015-06-27 09:48:12 progress=0.999290 cache=78161

• Connect postprocess: 8.43ms [0.25s]
  • Connect block: 1677.76ms [50.22s]
• Load block from disk: 6.18ms [0.19s]
  • Connect 889 transactions: 186.80ms (0.210ms/tx, 0.062ms/txin) [10.53s]
    • Verify 3033 txins: 963.75ms (0.318ms/txin) [47.21s]
    • Index writing: 3.79ms [0.17s]
    • Callbacks: 0.03ms [0.00s]
• Connect total: 1017.41ms [50.39s]
• Flush: 12.88ms [0.40s]
• Writing chainstate: 0.46ms [0.01s] @theuni , your hunch that id see "UpdateTip: new best=" was correct.

I am noticing some other things which seem related to this issue, probably what @theuni was talking about with "the current issue that slows down message processing while ActivateBestChain() is being run with lots of blocks to connect."

1- Seem more likely to occur when I am further back in the chain. I am 2 days behind, and the slow down is substantial. I am seeing 'UpdateTip' constantly in the debug, about once per second. Why is it running over and over again? 2- Other things are suspiciously slow as well. Though I have many connections to many peers (9), the blockchain download is going really slow. Looking at the bandwidth graph I am going through long periods of less then 10k throughput of block download with a few short bursts of 100k. Likewise, I am noticing the client still says '2 days behind' for a long time. I am having no connectivity issues. 3- Suddenly my client is all caught up. It went from '2 days behind' to 'Up to date' very quickly. Is it possible that all the blocks were downloaded, but the lag was just in verifying them locally? 4- I noticed in the gui debug window, the Peers tab, that querying agent information from the peers was no visible and apparently bottle necked as well.

Is there another bug filed for the 'ActivateBestChain' issue?

Yes this has been a known issue for a while and is related to holding the cs_main lock for a long time while syncing/catching up: #5851, #5664

I am not longer experiencing this issue in 0.11.0. Closing.