Empty array allocated on the Frozen Heap for a Collectible type?

[xoofx]

Hello folks,

Apologies, it's not a fully reproducible bug as we haven't tried yet to reproduce it with a simpler sample, but we have a suspicion.

We are investigating an error where we have the GC marking of frozen objects gc_heap::mark_ro_segments()that is crashing.

One place that we are curious about is in TryAllocateFrozenSzArray:

runtime/src/coreclr/vm/gchelpers.cpp

Lines 516 to 520 in 7486be8

	if (pArrayMT->ContainsPointers() && cElements > 0)
	{
	// For arrays with GC pointers we can only work with empty arrays
	return NULL;
	}

Where it seems that we could allow to allocate an empty array for collectible MethodTable in the Frozen heap. Shouldn't it be something like this instead?

    if (pArrayMT->Collectible() || (pArrayMT->ContainsPointers() && cElements > 0))
    {
        // For arrays with GC pointers we can only work with empty arrays
        return NULL;
    }

Before we investigate this further, any thoughts?

cc: @EgorBo

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[jkotas]

Before we investigate this further, any thoughts?

Yes, this looks like a bug. Could you please submit a PR with the fix?

[xoofx]

Yes, this looks like a bug. Could you please submit a PR with the fix?

Sure!

[jkotas]

There is CORJIT_FLAG_FROZEN_ALLOC_ALLOWED that handles most cases, but it does not cover shared generics. The shared generic code may have CORJIT_FLAG_FROZEN_ALLOC_ALLOWED set, but the actual instantiation can be collectible. I think you should be able to reproduce the crash using a pattern like this.

[xoofx]

Created PR #100444. We have tested a similar fix in our own fork, and it seems to be fixing our issues.