Sleep-wait on genesis block during init with -reindex #5243

1. 
   TheBlueMatt commented at 7:28 am on November 8, 2014: member

   This is an alternative to #5078…instead of throwing when chainActive.Tip() is missing (breaking what has otherwise traditionally been a global assumption) we just wait until at least genesis has been imported (its always first).
2. 
   sipa commented at 12:17 pm on November 8, 2014: member

   I wonder what would happen if you start with -reindex but don’t actually already have a blockchain locally. Or what if the genesis block entry on disk is broken.

   Maybe it makes sense to wait for either the genesis block present, or the importing process to be finished.

3. 
   TheBlueMatt commented at 6:40 pm on November 8, 2014: member

   If the import process finishes without genesis, then we have skipped the genesis-build and we should actually wipe chainstate or so.
4. 
   laanwj commented at 4:35 pm on November 12, 2014: member

   Agreed on concept, but this looks fragile. Polling every 10 milliseconds is also suboptimal - if this really needs to happen in a thread I would prefer to use a condition variable.

   Though as said in #5078 I’d prefer to split off the part of the import that looks for the Genesis block into a LocateGenesisBlock function. This would look in the first block file, look at the first block, and if it is not the Genesis block it would terminate. Waiting for the whole import to finish to detect that the genesis block is corrupt/missing would be suboptimal.

5. 
   sipa commented at 5:23 pm on November 14, 2014: member

   @TheBlueMatt Agree, I don’t think this makes things worse.
6. 
   sipa commented at 1:52 pm on November 18, 2014: member

   @TheBlueMatt Actually, it does. -reindex without any datadir currently works as expected. I believe that the code here will end up in an infinite sleep loop.
7. 
   sipa commented at 4:21 pm on November 18, 2014: member

   Tested ACK.

   I was wrong. Importing ends with a call to InitBlockIndex(), which fixes the no-genesis case in case nothing was imported.

8. laanwj added the label Bug on Dec 5, 2014
9. sleep-wait on genesis block during init with -reindex ff09e31a51
10. in src/init.cpp: in 86b84442e8 outdated

    1237@@ -1238,6 +1238,8 @@ bool AppInit2(boost::thread_group& threadGroup)
    1238             vImportFiles.push_back(strFile);
    1239     }
    1240     threadGroup.create_thread(boost::bind(&ThreadImport, vImportFiles));
    1241+    while (chainActive.Tip() == NULL) // Wait until ThreadImport has imported genesis
    

    ---

    ---

    

    laanwj commented at 10:17 am on December 5, 2014:

    This should check for fRequestShutdown, otherwise the initialization is not interruptible while waiting here (which make take a long time if the genesis block is corrupted).
11. TheBlueMatt force-pushed on Dec 21, 2014
12. 
    TheBlueMatt commented at 3:13 am on December 21, 2014: member

    @laanwj I agree, but overcomplicating this stuff for the incredibly rare/strange case of having a corrupt genesis block (especially if it works in that case, even if not well)…probably not worth it. Anyway, I added a log print and a check to fRequestShutdown.
13. laanwj merged this on Jan 26, 2015
14. laanwj closed this on Jan 26, 2015

    ---

15. laanwj referenced this in commit 2fae1875ea on Jan 26, 2015
16. 
    laanwj commented at 11:33 am on January 26, 2015: member

    Backported to 0.10 branch as c5044bc1693ced50ed070a27e7d2f3174202ace5
17. laanwj referenced this in commit c5044bc169 on Jan 26, 2015
18. reddink referenced this in commit f538a0c261 on May 27, 2020
19. MarcoFalke locked this on Sep 8, 2021

Contributors
TheBlueMatt sipa laanwj

Labels
Bug