-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
fix(qt): Fix overlapping directory lock attempts when restarting Dash Qt #6540
base: develop
Are you sure you want to change the base?
Conversation
WalkthroughThe pull request introduces a new conditional block at the end of the 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (2)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
@@ -359,6 +359,10 @@ void PrepareShutdown(NodeContext& node) | |||
|
|||
UnregisterAllValidationInterfaces(); | |||
GetMainSignals().UnregisterBackgroundSignalScheduler(); | |||
|
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.
/** Release all directory locks. This is used for unit testing only, at runtime
* the global destructor will take care of the locks.
*/
bitcoin says this one. Why should we do it manually?
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.
Because we implement functionality (restarting, source) that Bitcoin doesn't. The problem occurs because of the following order:
- Client started, global context initialized
- Managed context initializes
- Directory is locked
- Client fully loaded, user requests a reindex
- Managed context is destroyed
- New client instance is started with amended runtime arguments for reindex
- Old client instance finishes, global context is destroyed
- Directory is unlocked
The problem is that we start the new client (source) before the client gets to fully shutter down (source), which means the directory is still locked when the new instance is trying to run, which results in deviation from expected behavior. This is resolved by releasing the directory locks explicitly, to allow for the new instance to take over.
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.
Could probably wrap it in if (RestartRequested()) { ... }
to avoid executing it on shutdown
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.
Wrapped in RestartRequested()
and updated comment in latest push
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.
utACK 59f9c51
Expected Behavior
Actual Behavior
Additional Information
Running the client after reindexing is requested (i.e. on restart) was found to result in aAddressed by dash#6537, fix dropped from this PR.nullptr
-induced crash (see below) even thoughDeploymentActiveAfter()
handles anullptr
case (source). This has been resolved by returning early ifpindex
is anullptr
.Crash trace:
Breaking Changes
None expected
Checklist