Skip to content
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

[release/8.0-staging] Fix AsyncVoidMethodBuilder race condition around SynchronizationContext #99640

Merged

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Mar 12, 2024

Backport of #99461 to release/8.0-staging

/cc @stephentoub

Customer Impact

  • Customer reported
  • Found internally

Sporadic unhandleable crashes when using async void methods and there's a custom SynchronizationContext in play. There's a race condition that can result in the state of an object being cleared while that object is still in use, resulting in two reads of the same field first returning a non-null value and then returning a null value; the result of the second read is then dereferenced, producing a NullReferenceException that crashes the process.

Regression

  • Yes
  • No

Introduced in .NET Core 3.0. We've heard sporadic reports about the problem since but have never had a good repro to narrow it down.

Testing

A solid customer provided repro was provided that quickly crashed before the fix. After the fix, the issue no longer repros. It's also easy to see from code inspection that the problem can no longer occur.

Risk

Low. It's effectively just caching a read of a field into a local rather than reading that field twice (it also moves the read a bit earlier, but the data is observably readonly from construction, so moving it earlier doesn't matter.

This fixes a long-standing issue we've seen sporadically over the years but for which we just got a solid repro; the symptom is a sporadic unhandled null reference exception that crashes an app when using an async void method builder and a non-default SynchronizationContext. The issue is that, because of how state management is handled in the builder, the builder itself can be cleared while its SetResult method is running, and that means two reads of the _synchronizationContext field can end up returning a non-null value followed by a null value. The fix is to just cache the field into a local before completing the builder, and then only use the local state after.
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

@teo-tsirpanis teo-tsirpanis added this to the 8.0.x milestone Mar 12, 2024
@stephentoub stephentoub added Servicing-consider Issue for next servicing release review Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Mar 12, 2024
@stephentoub stephentoub requested a review from kouvel March 13, 2024 02:00
@stephentoub stephentoub merged commit 18b5fe6 into release/8.0-staging Mar 13, 2024
174 of 179 checks passed
@stephentoub stephentoub deleted the backport/pr-99461-to-release/8.0-staging branch March 13, 2024 02:05
@github-actions github-actions bot locked and limited conversation to collaborators Apr 12, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants