fix: Allow tx index to catch up with the block index in TestChainSetup dtor #5454
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…p dtor otherwise we might be destroying it while scheduler still has some work for it e.g. via BlockConnected signal
knst
reviewed
Jun 26, 2023
src/test/util/setup_common.cpp
Outdated
| // Allow tx index to catch up with the block index cause otherwise | ||
| // we might be destroying it while scheduler still has some work for it | ||
| // e.g. via BlockConnected signal | ||
| constexpr int64_t timeout_ms = 10 * 1000; |
There was a problem hiding this comment.
nit: why don't move timeout_ms inside while? so far as it constexpr variable definition, the overhead is zero, but it would be defined closer to usage
PastaPastaPasta
approved these changes
Jun 28, 2023
UdjinM6
added a commit
to UdjinM6/dash
that referenced
this pull request
Jul 25, 2023
…p dtor (dashpay#5454) ## Issue being fixed or feature implemented TL;DR: Should hopefully fix crashes like https://gitlab.com/dashpay/dash/-/jobs/4522256293 In dashd we flush all callbacks first and then destroy `g_txindex`. In tests we had to move `g_txindex` to `TestChainSetup` and its dtor is executed first, so the order is broken. It also explains why this crash happens so rare. In most cases tx index is up to date and you need some kind of a hiccup for scheduler to lag behind a bit. Basically, between `g_txindex.reset()` and `FlushBackgroundCallbacks` `BaseIndex::BlockConnected` finally arrives. But it’s processed on a (now) null instance hence a crash. If it’s earlier - it’s processed normally, if it’s later - it’s flushed without execution, so there is a tiny window to catch this crash. ## What was done? Give tx index a bit of time to process everything ## How Has This Been Tested? run tests (but this crash is rare 🤷♂️ ) ## Breaking Changes n/a ## Checklist: - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue being fixed or feature implemented
TL;DR: Should hopefully fix crashes like https://gitlab.com/dashpay/dash/-/jobs/4522256293
In dashd we flush all callbacks first and then destroy
g_txindex. In tests we had to moveg_txindextoTestChainSetupand its dtor is executed first, so the order is broken. It also explains why this crash happens so rare. In most cases tx index is up to date and you need some kind of a hiccup for scheduler to lag behind a bit. Basically, betweeng_txindex.reset()andFlushBackgroundCallbacksBaseIndex::BlockConnectedfinally arrives. But it’s processed on a (now) null instance hence a crash. If it’s earlier - it’s processed normally, if it’s later - it’s flushed without execution, so there is a tiny window to catch this crash.What was done?
Give tx index a bit of time to process everything
How Has This Been Tested?
run tests (but this crash is rare 🤷♂️ )
Breaking Changes
n/a
Checklist: