[release/7.0] Fix pGeneratedNewStub determination #80269
Merged
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.
Backport of #80128 to release/7.0
/cc @AaronRobinsonMSFT @ChrisAhna
Customer Impact
The problem came to light when a high-scale service started to see intermittent crashes after moving to Net7. These crashes occurred during concurrent marshaling of a layout-bearing struct which was defined in a non-FX module and which used a ByValArray to model the trailing part of the Win32 REPARSE_DATA_BUFFER structure (mimicked by the DataBuffer* types in the repro app).
See extensive details in #80127.
Testing
A repro sample was created and able to reproduce the crash 10 % of the time. With this fix, the issue was resolved.
Risk
Medium risk. This is a race condition that for interop stub generation and as such carries risk as the reproduction and verification is dependent on analysis of a complex system that is partially lock-free. This code has been checked in to .NET 8 though with a reproduction environment that was determined to be fix after the fix was applied.