System.ExecutionEngineException on call to GC.Collect()

[sunkin351]

In an attempt to see if a garbage collection would invalidate a Function Pointer returned from a call to Marshal.GetFunctionPointerForDelegate<T>(), I call GC.Collect() directly after and it throws an ExecutionEngineException. Is this a bug with .NET Core or am I doing something wrong?

.NET Runtime version: .NET Core 2.1

[sunkin351]

One other thing, It is a release build only thing... Not sure why.

[jkotas]

Could you please share a small program (e.g. as gist) that demonstrates this problem?

[sunkin351]

Literally, it's this:

delegate void TestDelegate();
static void Main(string[] args)
{
    IntPtr ptr = Marshal.GetFunctionPointerFromDelegate<TestDelegate>(SomeFunction); //Some function matching the Delegate signature
    GC.Collect();
}

I don't understand what I could be doing wrong. It's guaranteed to throw when I compile and run this in release mode on my machine.

[sunkin351]

One more thing to note, in debug mode, the pointer is still valid after the collection... Whereas normally it would throw a NullReferenceException, not caused by the pointer dereference. This should also be looked at.

[AaronRobinsonMSFT]

@sunkin351 I am unable to reproduce this issue. I am using .NET Core 2.1. Is there any chance you can gather a DMP of the crash?

Perhaps you could also provide some more details on your environment - i.e. OS, arch, etc.

using System;
using System.Runtime.InteropServices;

namespace ConsoleApp1
{
    class Program
    {
        static void SomeFunction()
        { }

        delegate void TestDelegate();
        static void Main(string[] args)
        {
            IntPtr ptr = Marshal.GetFunctionPointerForDelegate<TestDelegate>(SomeFunction); //Some function matching the Delegate signature
            GC.Collect();
        }
    }
}

[sunkin351]

This is Windows 10 x64 I'm running on. Can you walk me through getting the crash dump for you? I've never heard of being able to do this before now.

[AaronRobinsonMSFT]

There are a number of ways, but the easiest would probably be to use ProcDump. Above it was mentioned this occurred in 'Release', you can also debug the 'Release' build from Visual Studio and capture a DMP using https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Create_a_dump_file.

[sunkin351]

I just ran the test once more to make sure the issue was still present... Now its failing as it should (FailFast ExecutionEngineException upon callback of the garbage collected delegate.) instead of an ExecutionEngineException being thrown in GC.Collect()... Idk if that's actually what it was doing all along, cause it was pointing to GC.Collect() being the source of the error before, but now its the actual pointer invocation.

[sunkin351]

This started as an experiment to see what would happen if I tried to call a garbage collected delegate as if from native code, so now I know. But then there's an interesting situation where this doesn't happen in Debug. XD (i.e. I call the pointer after I run GC.Collect() and it runs as if I never invoked the GC)

[jkotas]

there's an interesting situation where this doesn't happen in Debug

GC is not guaranteed to collect all objects that are garbage. It can leave some object for next time.

In this particular case, it is most likely caused by the delegate lifetime being extended by the JIT with optimizations off (ie. in Debug).

[sunkin351]

I figured the no optimization thing would leave a few references. Thanks. Closing this now as this issue is mostly circumstantial, it would appear.