Ensure the FindReferenceTargetsCallback static constructor is called.#121558
Ensure the FindReferenceTargetsCallback static constructor is called.#121558AaronRobinsonMSFT merged 4 commits intodotnet:mainfrom
FindReferenceTargetsCallback static constructor is called.#121558Conversation
The code path in question is executed during a GC. This code path also allocates managed memory, which means it is incompatible to run during a GC. Ensuring the cctor run prior to any GC is the goal of this change.
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a critical race condition where the FindReferenceTargetsCallback static constructor could be invoked during garbage collection, causing managed memory allocations in a GC-incompatible code path. The fix ensures the static constructor runs before any GC callbacks are registered.
- Added an
EnsureInitialized()method to trigger the static constructor - Invoked
EnsureInitialized()inRegisterGCCallbacks()before GC callbacks are registered
|
We should do some validation for this:
|
Done. Found an additional issue when running |
|
@EgorBo FYI we're adding back two |
src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/ComWrappers.cs
Outdated
Show resolved
Hide resolved
|
Is it fine to keep it as is if we have a guarantee that And/Or are always imported as intrinsic? |
The problem are allocations caused by in non-optimized builds (when these reflection APIs are not expanded as intrinsics by the JIT). It is not really a type load. |
Yes, it would be ok to keep it as is if the JIT can be changed to guarantee that the generic Interlocked.And/Or is imported as an intrinsics that does not call anything that can GC allocate. |
|
/ba-g I've no clue what is going on, but none of it are these changes. |
The code path in question is executed during a GC. This code path also allocates managed memory, which means it is incompatible to run during a GC. Ensuring the cctor run prior to any GC is the goal of this change.
Fixes #121538