Fix self-deadlock when acquiring a shared SyncObject latch - #9120
Open
MochalovAlexey wants to merge 1 commit into
Open
Fix self-deadlock when acquiring a shared SyncObject latch#9120MochalovAlexey wants to merge 1 commit into
MochalovAlexey wants to merge 1 commit into
Conversation
Detect attempts to acquire SYNC_SHARED when the current thread already owns SYNC_EXCLUSIVE and unwind page-cache latches when propagating the resulting exception from VIO operations.
Member
No memory dump or stack trace ? What Firebird version is affected ?
What about other usages of SyncObject ? Other usages of bdb_sync ? Excuse me, but it looks like desperate attempt to workaround bug instead of properly fix it. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
This fixes a possible engine hang when the current thread tries to acquire
a SYNC_SHARED latch on a SyncObject that it already owns exclusively.
The hang was observed several times in a customer environment, but so far
it has not been possible to reproduce it manually with an unmodified build.
The problematic lock sequence was reproduced only by temporarily modifying
the code and running it in a debugger.
Instead of waiting on itself, SyncObject now detects this condition and
raises a dedicated error. Page-cache latches are unwound when the exception
propagates through VIO record operations, backout and savepoint cleanup.
The fix was originally implemented for the 3v and has been adapted
to the Firebird 5.