Skip to content

Fix SharedMem self-deadlock in blocked-processing recovery - #6497

Open
zacheryasc wants to merge 1 commit into
eProsima:masterfrom
zacheryasc:fix/sharedmem-recursive-reentry
Open

Fix SharedMem self-deadlock in blocked-processing recovery#6497
zacheryasc wants to merge 1 commit into
eProsima:masterfrom
zacheryasc:fix/sharedmem-recursive-reentry

Conversation

@zacheryasc

Copy link
Copy Markdown

Description

get_and_remove_blocked_processing() already holds node_->empty_cv_mutex
when it calls listener_processing_stop(), which attempts to lock the same
non-recursive std::mutex again. This re-entrancy self-deadlocks and spins
inside recover_blocked_processing() (issue #6485).

Clear listeners_status[i].is_processing in place instead, since the mutex is
already held. No mutex type or signature changed, so this is ABI- and
behavior-compatible and safe to backport. Adds a regression test that drives
the recovery path and asserts the listener is cleared without re-blocking.

@Mergifyio backport 3.2.x 2.14.x

Fixes #6485

Contributor Checklist

  • Commit messages follow the project guidelines.
  • The code follows the style guidelines of this project.
  • Tests that thoroughly check the new feature have been added/Regression tests checking the bug and its fix have been added; the added tests pass locally
  • N/A Any new/modified methods have been properly documented using Doxygen. (no public API change; existing Doxygen block on the method is still accurate)
  • N/A Any new configuration API has an equivalent XML API (with the corresponding XSD extension)
  • Changes are backport compatible: they do NOT break ABI nor change library core behavior.
  • Changes are API compatible.
  • N/A New feature has been added to the versions.md file (if applicable).
  • N/A New feature has been documented/Current behavior is correctly described in the documentation.
  • Applicable backports have been included in the description.

Reviewer Checklist

  • The PR has a milestone assigned.
  • The title and description correctly express the PR's purpose.
  • Check contributor checklist is correct.
  • If this is a critical bug fix, backports to the critical-only supported branches have been requested.
  • Check CI results: changes do not issue any warning.
  • Check CI results: failing tests are unrelated with the changes.

get_and_remove_blocked_processing() already holds node_->empty_cv_mutex
when it calls listener_processing_stop(), which attempts to lock the same
non-recursive std::mutex again. This re-entrancy self-deadlocks and spins
inside recover_blocked_processing() (issue eProsima#6485).

Clear listeners_status[i].is_processing in place instead, since the mutex
is already held. Adds a regression test that drives the recovery path and
asserts the listener is cleared without re-blocking.

Signed-off-by: Zachery Aaron Shores-Chmielewski <zacheryasc@gmail.com>
@IloveZhengYi

Copy link
Copy Markdown

thanks for your work! Hope the maintainers can get this merged soon. 👍

@MiguelCompany
MiguelCompany self-requested a review August 10, 2026 05:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Infinite loop in SHM SharedMemManager::Port::recover_blocked_processing() caused by non-recursive mutex re-entrancy

2 participants