Globals aren’t too nice because they hide dependencies, also they make testing harder.
Fix that by removing some.
Globals aren’t too nice because they hide dependencies, also they make testing harder.
Fix that by removing some.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
src/node/
and src/wallet/
code to node::
and wallet::
namespaces by ryanofsky)If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Needed for a later commit
Can be reviewed with --color-moved=dimmed-zebra --color-moved-ws=ignore-all-space
330@@ -348,6 +331,11 @@ void BlockManager::Unload()
331 }
332
333 m_block_index.clear();
334+
335+ vinfoBlockFile.clear();
336+ nLastBlockFile = 0;
337+ setDirtyBlockIndex.clear();
338+ setDirtyFileInfo.clear();
In commit “Make blockstorage globals private members of BlockManager” (fad81b7a0f8ea300708321c3fcae7f75cade14ba)
Is this a pure refactor, or is there some change in behavior here? It seems like these lines are being moved from UnloadBlockIndex
to BlockManager::Unload
but neither function is directly calling the other.
It might be good to move this change to a separate commit before the “make private members” commit with an explanation about why it’s safe. Not saying it’s unsafe. It’s just not obviously safe.
UnloadBlockIndex
calls chainman.Unload()
, which again should call BlockManager::Unload
. So only change should be the destruction order
UnloadBlockIndex
callschainman.Unload()
, which again should callBlockManager::Unload
. So only change should be the destruction order
So there is no code in some other place calling BlockManager::Unload
and now having extra state cleared?
If you put this change in a separate commit and explicitly say whether it’s supposed to change behavior and maybe say how it doesn’t change behavior, it can make it easier for future reviewers and future regression bugfixers, who I think would logically be asking these questions.
Thanks Ryan.
Ok, you finally convinced me
This is a refactor and safe to do because:
* UnloadBlockIndex calls ChainstateManager::Unload, which calls
BlockManager::Unload
* Only unit tests call Unload directly
This is needed to turn globals into member variables. Otherwise, this
will lead to issues:
runtime error: reference binding to null pointer of type 'CBlockFileInfo'
#0 in std::vector<CBlockFileInfo, std::allocator<CBlockFileInfo> >::operator[](unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_vector.h:1046:2
#1 in BlockManager::FlushBlockFile(bool, bool) src/node/blockstorage.cpp:540:47
#2 in CChainState::FlushStateToDisk(BlockValidationState&, FlushStateMode, int) src/validation.cpp:2262:28
#3 in CChainState::ResizeCoinsCaches(unsigned long, unsigned long) src/validation.cpp:4414:15
#4 in validation_chainstate_tests::validation_chainstate_resize_caches::test_method() src/test/validation_chainstate_tests.cpp:66:12
-BEGIN VERIFY SCRIPT-
ren() { sed -i "s/\<$1\>/$2/g" $( git grep -l "$1" ./src/ ) ; }
ren vinfoBlockFile m_blockfile_info
ren nLastBlockFile m_last_blockfile
ren fCheckForPruning m_check_for_pruning
ren setDirtyBlockIndex m_dirty_blockindex
ren setDirtyFileInfo m_dirty_fileinfo
-END VERIFY SCRIPT-
337+ m_dirty_blockindex.clear();
338+ m_dirty_fileinfo.clear();
339+}
340+
341+bool BlockManager::WriteBlockIndexDB()
342+{
141@@ -120,6 +142,16 @@ class BlockManager
142
143 CBlockIndex* LookupBlockIndex(const uint256& hash) const EXCLUSIVE_LOCKS_REQUIRED(cs_main);
144
145+ /** Get block file info entry for one block file */
Would be it worth mentioning that this function is only used by the unit tests? If yes, can add to #24002.
0- /** Get block file info entry for one block file */
1+ /** Get block file info entry for one block file. Currently only used for unit tests. */