Pruned blocks sometimes cause other blocks in the index (mostly descendants of orphans) to have invalid parents, which may trip an assert pindexWalk->pprev (#692) on startup. Additionally, because block indexes don't own their own hash values, removing the index from mapBlockIndex where the hash is allocated may lead to a use-after-free corrupting the hash of a block written to disk (may be the cause of https://github.com/Veil-Project/veil/issues/930#issuecomment-819166828).
Solution
Select pruning candidates in two rounds: first, based on height. Then, add all descendants of the blocks chosen in the first round.
For the memory issue, add a shared_ptr field to CBlockIndex that provides the hash value when the block is removed from mapBlockIndex. This will manage the memory of the hash for the lifetime of the object (which is forever anyway) and allows for efficient sharing and copying as usual (unique_ptr does not).
CaveSpectre11
commented
3 years ago
Problem
Pruned blocks sometimes cause other blocks in the index (mostly descendants of orphans) to have invalid parents, which may trip an assert
pindexWalk->pprev(#692) on startup. Additionally, because block indexes don't own their own hash values, removing the index frommapBlockIndexwhere the hash is allocated may lead to a use-after-free corrupting the hash of a block written to disk (may be the cause of https://github.com/Veil-Project/veil/issues/930#issuecomment-819166828).Solution
Select pruning candidates in two rounds: first, based on height. Then, add all descendants of the blocks chosen in the first round.
For the memory issue, add a
shared_ptrfield to CBlockIndex that provides the hash value when the block is removed from mapBlockIndex. This will manage the memory of the hash for the lifetime of the object (which is forever anyway) and allows for efficient sharing and copying as usual (unique_ptr does not).Testing
Via regtest. See https://github.com/Veil-Project/veil/issues/692#issuecomment-886256882