What does Array.Clear actually do under the covers

Question

I'm looking for a answer to what the Array.Clear(...) method does under the covers in C#.

I've looked at the IL, but that isn't really yielding any clues, since it simply calls the System.Array::Clear(...) method in mscorlib, which then calls an unmanaged portion of the CLR that I can't observe.

The reason why I am asking this, is that I am occasionally getting an SEHException thrown by my call to Array.Clear, and I can't seem to figure out why it is happening.

Unfortunately, Microsoft seems to be a little tight-lipped about what it might mean when the exception is thrown...

From: http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.sehexception(v=VS.100).aspx

Any SEH exception that is not automatically mapped to a specific exception is mapped to the SEHException class by default. For more information, search on "unmanaged exceptions" and "Structured Exception Handling" in the MSDN Library.

Answer 1

It's easiest to envision Array.Clear being written like so

public static void Array.Clear<T>(T[] array) {
  for (int i = 0; i < array.Length; i++) {
    array[i] = default(T);
  }
}

I realize Array.Clear is not actually a generic method, i'm trying to demonstrate a close mapping of what's going on under the hood. Really though it's closer to

memcopy(&array, 0, array.Length * sizeof(T));

If this code is throwing an SEHException then the most likely cause is the memory around the source array is corrupted. The most likely source is an incorrect PInvoke or COM interop call.

Answer 2

You can see that kind of code in the SSCLI20 source code. Which looks like this with all the noise removed:

FCIMPL3(void, SystemNative::ArrayClear, ArrayBase* pArrayUNSAFE, INT32 iIndex, INT32 iLength)
{
    BASEARRAYREF pArray = (BASEARRAYREF)pArrayUNSAFE;
    // error checks
    //.. 
    char* array = (char*)pArray->GetDataPtr();
    int size = pArray->GetMethodTable()->GetComponentSize();
    ZeroMemory(array + (iIndex - lb) * size, iLength * size);
}

In other words, it simply blasts 0 bytes into the elements. The only way to get an SEHException is through a processor fault. GC heap corruption. Review any pinvoke or COM interop code.