Shut down if trying to connect a corrupted block

The call to CheckBlock() in ConnectBlock() is redundant with calls to it
prior to storing a block on disk. If CheckBlock() fails with an error
indicating the block is potentially corrupted, then shut down
immediately, as this is an indication that the node is experiencing
hardware issues.  (If we didn't shut down, we could go into an infinite
loop trying to reconnect this same bad block, as we're not setting the
block's status to FAILED in the case where there is potential
corruption.)

If CheckBlock() fails for some other reason, we'll end up flagging this
block as bad (perhaps some prior software version "let a bad block in",
as the comment indicates), and not trying to connect it again, so this
case should be properly handled.
This commit is contained in:
Suhas Daftuar 2018-03-05 10:42:26 -05:00
parent 9e2ed253f5
commit 0e7c52dc6c

View file

@ -1791,8 +1791,15 @@ bool CChainState::ConnectBlock(const CBlock& block, CValidationState& state, CBl
// is enforced in ContextualCheckBlockHeader(); we wouldn't want to
// re-enforce that rule here (at least until we make it impossible for
// GetAdjustedTime() to go backward).
if (!CheckBlock(block, state, chainparams.GetConsensus(), !fJustCheck, !fJustCheck))
if (!CheckBlock(block, state, chainparams.GetConsensus(), !fJustCheck, !fJustCheck)) {
if (state.CorruptionPossible()) {
// We don't write down blocks to disk if they may have been
// corrupted, so this should be impossible unless we're having hardware
// problems.
return AbortNode(state, "Corrupt block found indicating potential hardware failure; shutting down");
}
return error("%s: Consensus::CheckBlock: %s", __func__, FormatStateMessage(state));
}
// verify that the view's current state corresponds to the previous block
uint256 hashPrevBlock = pindex->pprev == nullptr ? uint256() : pindex->pprev->GetBlockHash();