The scope of the lock should be limited to just guarding m_warnings as anything listening on NotifyAlertChanged may execute code that requires the lock as well.
Fixes #30400
The scope of the lock should be limited to just guarding m_warnings as
anything listening on `NotifyAlertChanged` may execute code that
requires the lock as well.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For detailed information about the code coverage, see the test coverage report.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | TheCharlatan, maflcko, glozow, willcl-ark, stickies-v |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
ACK 6af51e819847e737449609daa214e16f9453e85d
lgtm ACK 6af51e819847e737449609daa214e16f9453e85d
ACK 6af51e819847e737449609daa214e16f9453e85d
Not familiar with this code at all, but it looks like the handler function handleNotifyAlertChanged calls getStatusBarWarnings
https://github.com/bitcoin/bitcoin/blob/bd5d1688b4311e21c0e0ff89a3ae02ef7d0543b8/src/qt/clientmodel.cpp#L256-L260
which calls Node::getWarnings()
https://github.com/bitcoin/bitcoin/blob/bd5d1688b4311e21c0e0ff89a3ae02ef7d0543b8/src/qt/clientmodel.cpp#L164-L167
which calls GetMessages()
https://github.com/bitcoin/bitcoin/blob/bd5d1688b4311e21c0e0ff89a3ae02ef7d0543b8/src/node/interfaces.cpp#L101
and GetMessages takes the lock as well
https://github.com/bitcoin/bitcoin/blob/bd5d1688b4311e21c0e0ff89a3ae02ef7d0543b8/src/node/warnings.cpp#L44-L46
ACK 6af51e819847e737449609daa214e16f9453e85d
It's generally best-practice to hold locks for the shortest possible time to minimize contention.
ACK 6af51e819847e737449609daa214e16f9453e85d
This seems quite tricky to have test coverage for (since it only manifests in bitcoin-qt), and unfortunately the EXCLUSIVE_LOCKS_REQUIRED(!m_mutex) annotations didn't catch this either, so I'm not sure if there's much more we can do to prevent regressions?
Review note: easy steps to reproduce are here. Thanks again for finding this @achow101 .
Milestone
28.0