GUI misses some header updates when in IBD #65

1. 
   fanquake commented at 4:39 am on August 15, 2020: member

   Moved from https://github.com/bitcoin/bitcoin/issues/9464. Low prio, could probably just be closed as wont-fix.

   OSX 10.12.2, Qt 5.7.1, master at 2a524b8e8fe69ef487fd8ea1b4f7a03f473ed201.

   Running with bitcoin-qt -reindex-chainstate, “Number of blocks left” in the modal overlay never updates, and remains as “Unknown. Syncing Headers (446424)…”. Even though we’ve synced > 200'000 blocks.

2. fanquake added the label Bug on Aug 15, 2020
3. 
   maflcko commented at 5:56 am on August 15, 2020: contributor

   This is only a temporary glitch. Copy of my previous comment:

   Confirmed that the issue is still present in current master (5180a86c96) and “fixes itself”/ is worked around when the next header is sent to you. C.f. my comment https://github.com/bitcoin/bitcoin/issues/9464#issuecomment-270362394

4. 
   arejula27 commented at 3:43 pm on March 27, 2026: none
5. 
   arejula27 commented at 4:18 pm on March 27, 2026: none

   During my first full sync I was able to dig a little deeper into what might be causing this.

   How to reproduce

   I was running my first IBD from an external SSD. At some point the core crasshed cuz a malformed hash due to a disk issue, so I remounted the SSD with sync option.

   02026-03-27T11:35:06Z LevelDB read failure: Corruption: block checksum mismatch: /home/arejula27/.bitcoin/chaindata/chainstate/009670.ldb
   12026-03-27T11:35:06Z Fatal LevelDB error: Corruption: block checksum mismatch: /home/arejula27/.bitcoin/chaindata/chainstate/009670.ldb
   22026-03-27T11:35:06Z You can use -debug=leveldb to get more complete diagnostic messages
   32026-03-27T11:35:06Z [error] Error reading from database, shutting down.
   42026-03-27T11:35:06Z [error] Error reading from database: Fatal LevelDB error: Corruption: block checksum mismatch: /home/arejula27/.bitcoin/chaindata/chainstate/009670.ldb
   

   When I restarted Bitcoin Core, the chainstate had only persisted up to block ~534k, even though the block files on disk already blocks up to ~634k and the block index had ~942k headers from the previous session. On startup, ActivateBestChain() had to reconnect the ~100k blocks from 534k to 634k to rebuild the chainstate, which took around 57 minutes.

    0
    1
    22026-03-27T14:16:25Z block tree size = 942189
    32026-03-27T14:16:25Z nBestHeight = 534981
    42026-03-27T14:16:25Z initload thread start
    52026-03-27T14:16:25Z init message: Starting network threads…
    62026-03-27T14:16:29Z UpdateTip: new best=... height=534982  ← initload reconnecting blocks
    7...
    8
    92026-03-27T15:13:39Z initload thread exit          ← 57 minutes later
   102026-03-27T15:13:39Z New outbound-full-relay v2 peer connected: version: 70016, blocks=77225, peer=97
   112026-03-27T15:13:39Z New block-relay-only v2 peer connected: version: 70016, blocks=942482, peer=99
   122026-03-27T15:13:39Z Synchronizing blockheaders, height: 942482 (~100.00%)
   132026-03-27T15:13:40Z New block-relay-only v2 peer connected: version: 70016, blocks=941347, peer=100
   142026-03-27T15:13:41Z UpdateTip: new best=00000000000000000001c368b208bb4614a3359cd44a0d47e5574e7c8d0be923 height=634604 version=0x20000000 log2_work=92.029697 tx=538756745 date='2020-06-13T21:19:45Z' progress=0.404176 cache=205.0MiB(1488013txo)
   

   During that entire reconnection period, the node considers itself to still be “loading blocks”, which means it ignores incoming headers from peers. Meanwhile, the GUI already had 942k headers loaded from the block index on disk, but bestHeaderDate, the timestamp used to estimate sync progress, was hours out of date, since no new headers had been received. This caused the progress overlay to display “Unknown” for both blocks remaining and estimated time. Once the reconnection finished, the node accepted a new peer connection, fetched the latest headers, and the GUI immediately started showing correct progress information.

   Possible cause

   During the UTXO rebuild phase (e.g. after a chainstate corruption), LoadingBlocks() returns true, which causes the node to reject incoming headers from peers. This means bestHeaderDate, the timestamp of the last known header, doesn’t get refreshed

   As time passes, bestHeaderDate becomes stale. After ~4 hours (HEADER_HEIGHT_DELTA_SYNC * nPowTargetSpacing), estimateNumHeadersLeft exceeds the threshold of 24 and the GUI falls into the else branch, displaying “Unknown” for blocks remaining. Meanwhile, UpdateHeaderSyncLabel() computes a percentage that rounds to 100.0% because the few estimated missing headers are negligible relative to the total (~942k). This creates a contradictory display: “Unknown. Syncing Headers (942188, 100.0%)”.

   Proposal

   The “Unknown” + “100.0%” contradiction happens because the percentage rounds up even when there are still headers left. Truncating instead of rounding would make it consistent, 100.0% would only show when headers are actually up to date. I have write the code, i will do a PR in the next days :D

Contributors
fanquake maflcko arejula27

Labels
Bug