-
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
Race in RuntimeTypeCache / metadata reading #81884
Comments
Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis Issue DetailsIt happened to me twice but could not reproduce it reliably.
Version: 8.0.100-alpha.1.23068.1
|
Tagging subscribers to this area: @dotnet/area-system-reflection Issue DetailsIt happened to me twice but could not reproduce it reliably.
Version: 8.0.100-alpha.1.23068.1
|
@EgorBo This is likely caused by missing memory barrier when allocation RuntimeType objects on FOD. Could you please take a look? |
hm.. in general, RtunimeType objects are expected to be allocated and cached under a lock here https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/typehandle.cpp#L366 |
Here is what is likely happening: Thread 1: Acquires the lock Thread 2: Observes the pointer to the published instance, but does not observe the initialized instance (the writes that are initializing the instance are still pending) Thread 1: Releases the lock that flushes pending memory writes |
BTW: We avoid this sort of problem for regular managed objects and managed references by issuing memory barrier as part of the GC write barrier. |
The fix should be to change this https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/typehandle.cpp#L380 and other similar places to use VolatileStore. |
Ok, I'll go check all the places I touched related to FOH for that, thanks for the analysis! |
It happened to me twice but could not reproduce it reliably.
Version: 8.0.100-alpha.1.23068.1
The text was updated successfully, but these errors were encountered: