-
Notifications
You must be signed in to change notification settings - Fork 37.7k
Sleep-wait on genesis block during init with -reindex #5243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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. |
If the import process finishes without genesis, then we have skipped the genesis-build and we should actually wipe chainstate or so. |
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. |
@TheBlueMatt Agree, I don't think this makes things worse. |
@TheBlueMatt Actually, it does. |
Tested ACK. I was wrong. Importing ends with a call to InitBlockIndex(), which fixes the no-genesis case in case nothing was imported. |
@@ -1238,6 +1238,8 @@ bool AppInit2(boost::thread_group& threadGroup) | |||
vImportFiles.push_back(strFile); | |||
} | |||
threadGroup.create_thread(boost::bind(&ThreadImport, vImportFiles)); | |||
while (chainActive.Tip() == NULL) // Wait until ThreadImport has imported genesis |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
86b8444
to
ff09e31
Compare
@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. |
ff09e31 sleep-wait on genesis block during init with -reindex (Matt Corallo)
Backported to 0.10 branch as c5044bc |
Rebased-From: ff09e31 Github-Pull: bitcoin#5243 (cherry picked from commit c5044bc)
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).