Page MenuHomePhabricator

[avalanche] Fix a reversed lock order in ReattemptInitialBroadcast
ClosedPublic

Authored by Fabien on Feb 8 2022, 18:07.

Details

Reviewers
tyler-smith
Group Reviewers
Restricted Project
Maniphest Tasks
Restricted Maniphest Task
Commits
rABCc8e2c0dccbc8: [avalanche] Fix a reversed lock order in ReattemptInitialBroadcast
Summary

The expected lock order is cs_vNodes => cs_peerManager. Unfortunately the ReattemptInitialBroadcast method locks the opposite way, and causes a potential deadlock that has been uncovered by the getavaaddr functional test that mocks the scheduler time (for the statistics to be updated) and increase the chance of the reverse lock condition to occur.

Ref T1696.

Test Plan
ninja all check-all

With debug:

for i in {1..1000}; do ./test/functional/test_runner.py abc_p2p_getavaaddr || break; done

Diff Detail

Repository
rABC Bitcoin ABC
Branch
avalanche_fix_potential_deadlock
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 18206
Build 36220: Build Diffbuild-without-wallet · build-debug · build-clang-tidy · lint-circular-dependencies · build-clang · build-diff
Build 36219: arc lint + arc unit

Event Timeline

Fabien requested review of this revision.Feb 8 2022, 18:07
tyler-smith added a subscriber: tyler-smith.

This split makes sense and looks correctly implemented. Had to brush up on iterator semantics to make sure I was understanding the behavior around erasing the item and assigning to the next value but it looks good.

This revision is now accepted and ready to land.Feb 9 2022, 03:40

Curly bracket in commit message looks wonky

Fabien retitled this revision from [avalanche} Fix a reversed lock order in ReattemptInitialBroadcast to [avalanche] Fix a reversed lock order in ReattemptInitialBroadcast.Feb 9 2022, 08:11