Skip to content

[SourceKit] Resolve a nondeterministic deadlock in SourceKit while cancelling #42258

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

Merged
merged 1 commit into from
May 19, 2022

Conversation

ahoppen
Copy link
Member

@ahoppen ahoppen commented Apr 8, 2022

This fixes a race-conditioned deadlock which could occur while cancelling SourceKit AST build request

We have one thread that claimed CancellationRequestCallbackMtx in SwiftASTConsumer::requestCancellation and wants to claim ConsumersAndResultMtx in ASTBuildOperation::requestConsumerCancellation

Another thread claimed ConsumersAndResultMtx in ASTBuildOperation::schedule and now wants to claim CancellationRequestCallbackMtx in SwiftASTConsumer::removeCancellationRequestCallback.

In both cases we could actually release one lock before claiming the other.

Fixes rdar://90870793

…ncelling

This fixes a race-conditioned deadlock which could occur while cancelling SourceKit AST build request

We have one thread that claimed `CancellationRequestCallbackMtx` in `SwiftASTConsumer::requestCancellation` and wants to claim `ConsumersAndResultMtx` in `ASTBuildOperation::requestConsumerCancellation`

Another thread claimed `ConsumersAndResultMtx` in `ASTBuildOperation::schedule` and now wants to claim `CancellationRequestCallbackMtx` in `SwiftASTConsumer::removeCancellationRequestCallback`.

In both cases we could actually release one lock before claiming the other.

Fixes rdar://90870793
@ahoppen ahoppen requested a review from bnbarham April 8, 2022 08:46
@ahoppen
Copy link
Member Author

ahoppen commented Apr 8, 2022

@swift-ci Please smoke test

1 similar comment
@ahoppen
Copy link
Member Author

ahoppen commented Apr 8, 2022

@swift-ci Please smoke test

Copy link
Contributor

@bnbarham bnbarham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this should fix it, would it be worth narrowing the CancellationRequestCallbackMtx lock as well? Ie. requestCancellation and setCancellationRequestCallback should only call the callback outside the lock

Comment on lines +1162 to +1165
if (Result) {
informConsumer(Consumer);
return true;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally this would be outside the lock as well - maybe check !Result here and then the same check outside the lock to either inform/add cancellation?

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.

2 participants