Repeated commits for mark array #75207
Description
Suppose we have a region that has the associated mark array committed. It is returned to the free region list through return_free_region and then got back to the heap through get_free_region. The code in init_heap_segment called by get_free_region will reset the heap_segment_flags_ma_committed flag and we will commit the mark array again when we need it.
In case we are running on a supported platform where duplicated virtual_commit to the same address range is non-fatal, it is fine.
On certain platforms, repeated virtual_commit to the same address range is fatal. Even in the case that it isn't fatal, in the presence of a hard limit, this will repeatedly consume the hard limit, so we will eventually "run out of memory" just because the number is leaked and we think the system is running out of committed bytes when it actually isn't.
To reproduce the issue, check out my private branch here.
Note: This branch requires the use of
heap_hard_limit, it will assert and crash otherwise.
The branch features a heap segment analyzer that can be used to detect the case when we have overlapped virtual commits, which can be used to detect the bug as follow:
We can run GCPerfSim with these parameters (with a release build of the Core_Root built on the branch):
GCPerfSim.dll -tc 6 -tagb 100.0 -tlgb 0.01 -lohar 0 -pohar 0 -sohsi 10 -lohsi 0 -pohsi 0 -sohsr 100-4000 -lohsr 102400-204800 -pohsr 100-4000 -sohpi 10 -lohpi 0 -sohfi 0 -lohfi 0 -pohfi 0 -allocType reference -testKind time
and these environment variables:
COMPlus_GCHeapCount=6
COMPlus_GCHeapHardLimit=1C200000
COMPlus_GCServer=1
This will generate a file named andrew.txt, running analyze.py with that file will lead to the tool detecting the overlap.