Skip to content

Conversation

@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Jan 22, 2024

Backport of #95769 and #97353 to release/8.0-staging

/cc @davidwrighton @HJLeee

Customer Impact

  • Customer reported
  • Found internally

This fault causes the .NET runtime to seg fault accessing a NULL pointer on startup when reading or writing the value of a static variable. The expected behavior is that access to the static variable will succeed. The customer did not report this bug with an issue, instead they filed PR #95769 to fix the issue. Internally this was also reported by a high scale service which has just been updated to use .NET 8. In addition, while looking at the internal repro, I found a different race condition that appeared to be possible, and was also fixable by the addition of a VolatileStore/VolatileLoadWithoutBarrier pair of commands (PR #97353).

Regression

  • Yes
  • No

This is not a regression, but issues of this form were not seen with .NET 6 or 7 on previous versions of the internal high scale service. It is possible that some pre-existing locking contention was present that was fixed in .NET 8.

Testing

This is a race condition deep in the runtime at this time, we have no means to provide effective testing on this.

Risk

Low. This fix takes code which is using a series of interlocked and volatile operations which did not correct address the possible race conditions to using a simple lock to protect the identified issue.

IMPORTANT: If this backport is for a servicing release, please verify that:

  • The PR target branch is release/X.0-staging, not release/X.0.

  • If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

- Remove race condition where it is possible that an updated dynamic statics info pointer is published without ensuring that the data is also considered written.
- Use VolatileLoadWithoutBarrier at the read site (where locks are not taken) to ensure that there are no difficult to examine reads of this pointer.
@davidwrighton davidwrighton requested a review from jkotas January 23, 2024 23:04
@davidwrighton davidwrighton added the Servicing-consider Issue for next servicing release review label Jan 23, 2024
Copy link
Member

@jeffschwMSFT jeffschwMSFT left a comment

Choose a reason for hiding this comment

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

approved. we will take for consideration in 8.0.x

@rbhanda rbhanda added this to the 8.0.3 milestone Jan 25, 2024
@rbhanda rbhanda added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jan 25, 2024
@jeffschwMSFT
Copy link
Member

@davidwrighton is this ready to merge? it is marked draft

@davidwrighton davidwrighton marked this pull request as ready for review February 9, 2024 20:04
@davidwrighton
Copy link
Member

Yes this is ready to merge.

@jeffschwMSFT jeffschwMSFT merged commit c804f58 into release/8.0-staging Feb 9, 2024
@jkotas jkotas deleted the backport/pr-95769-to-release/8.0-staging branch February 21, 2024 00:47
@github-actions github-actions bot locked and limited conversation to collaborators Mar 22, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-VM-coreclr Servicing-approved Approved for servicing release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants