-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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] Always zero-init if object contains pointers #100426
Conversation
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
There was a problem hiding this 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
Waiting for #100622 to merge, so that all tests are green. |
@jeffschwMSFT @VSadov - please assess failures and merge today. |
This is a NativeAOT specific fix for |
LGTM |
Backport of #100265 to release/8.0-staging
Customer Impact
This was seen to cause failures due to heap corruption in local run-to-failure runs.
Using
GC.AllocateUninitializedArray()
API with reference-containing element types on NativeAOT would introduce silent heap corruptions and eventually cause a crash at the next full GC.Such failures would be extremely difficult to diagnose if happen in a real application.
Regression
Allowing reference types for pinned
GC.AllocateUninitializedArray()
was a new addition to the public API.The intended semantics of AllocateUninitializedArray with reference containing element types is to ignore the "Unintialized" part as GC heap does not expect uninitialized object references.
Historically, the check for this combination (reference-containing+uninitialized) was present in CoreCLR, but was not ported to NativeAOT as a part of the above change.
Testing
Regular tests + a test scenario that is sensitive to this scenario was added.
Risk
Low: This is matching the long existing behavior on CoreCLR.