Enable GC double reporting detection #107986
Conversation
This change adds detection of double reporting of stack slots and registers during GC stack walk. The detection is disabled by default and can be enabled using the DOTNET_EnableGCHoleMonitoring env variable. If a double reporting is found, it triggers an assert in both release and debug builds of the runtime.
|
Tagging subscribers to this area: @dotnet/gc |
|
Should this be on by default for GC stress runs? |
| @@ -278,6 +278,7 @@ CONFIG_STRING_INFO(INTERNAL_SkipGCCoverage, W("SkipGcCoverage"), "Specify a list | |||
| RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_StatsUpdatePeriod, W("StatsUpdatePeriod"), 60, "Specifies the interval, in seconds, at which to update the statistics") | |||
| RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_GCRetainVM, W("GCRetainVM"), 0, "When set we put the segments that should be deleted on a standby list (instead of releasing them back to the OS) which will be considered to satisfy new segment requests (note that the same thing can be specified via API which is the supported way)") | |||
| RETAIL_CONFIG_DWORD_INFO(EXTERNAL_gcAllowVeryLargeObjects, W("gcAllowVeryLargeObjects"), 1, "Allow allocation of 2GB+ objects on GC heap") | |||
| RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_EnableGCHoleMonitoring, W("EnableGCHoleMonitoring"), 0, "Enable checks to proactively watch for possible GC holes") | |||
There was a problem hiding this comment.
Perhaps we can enable it some of the GC tests?
There was a problem hiding this comment.
I have just added a change that enables it also when GC stress is enabled, as @jkotas has suggested. So all the CI runs with GC stress will automatically execute this stuff.
| @@ -201,7 +203,9 @@ static void ScanStackRoots(Thread * pThread, promote_func* fn, ScanContext* sc) | |||
| #if defined(FEATURE_EH_FUNCLETS) | |||
| flagsStackWalk |= GC_FUNCLET_REFERENCE_REPORTING; | |||
| #endif // defined(FEATURE_EH_FUNCLETS) | |||
| gcctx.pScannedSlots = new SetSHash<Object**, PtrSetSHashTraits<Object**> >(); | |||
There was a problem hiding this comment.
I'd prefer to see this not allocate at all unless duplicate detection is turned on. The performance impact doesn't really concern me, but it's just an extra opportunity for a process that is nearly out of memory to get an unlucky OOM in a new and horrible place, as I don't know think flowing a threw this code during the middle of a GC will leave the GC in a consistent state. Alternatively, you could do a nothrow'ing new, and have a null check around the use of the pScannedSlot variable.
There was a problem hiding this comment.
Sigh, my mistake, that was not intended. Happened accidentally by transforming the previous state of the PR to the current one.
This change adds detection of double reporting of stack slots and registers during GC stack walk. The detection is disabled by default and can be enabled using the DOTNET_EnableGCHoleMonitoring env variable.
If a double reporting is found, it triggers an assert in both release and debug builds of the runtime.