Finalizer called without ctor in optimized compilation case

[peppy]

We recently encountered a bug where an object expected to be in an initialized state at point of finalizing was not. Minimal reproduction case:

using System;
using System.Diagnostics;

namespace ReproduceFinalizerFailure
{
    class Program
    {
        public static bool CtorReached;
        public static bool FinalizerReached;

        static void Main()
        {
            try
            {
                GetObject();
            }
            catch
            {
            }

            GC.Collect();
            GC.WaitForPendingFinalizers();

            Trace.Assert(!CtorReached, "Constructor should not be reached");
            Trace.Assert(!FinalizerReached, "Finalizer should not be reached");
        }

        private static void GetObject()
        {
            var obj = throwException();
            new FinalizingObject(obj);
        }

        private static object throwException()
        {
            throw new Exception();
        }
    }

    class FinalizingObject
    {
        public FinalizingObject(object obj) => Program.CtorReached = true;

        ~FinalizingObject() => Program.FinalizerReached = true;
    }
}

➜  ReproduceFinalizerFailure  dotnet --version
3.1.100
➜  ReproduceFinalizerFailure  dotnet run -c Release
Process terminated. Assertion Failed
Finalizer should not be reached
   at ReproduceFinalizerFailure.Program.Main() in /Users/dean/Projects/ReproduceFinalizerFailure/ReproduceFinalizerFailure/Program.cs:line 27

This only happens with build configuration Release and debugger detached.

Potentially related to #764.

[mikedn]

This looks like https://github.com/dotnet/coreclr/issues/2478

The problem is that the object is allocated before the constructor arguments are evaluated, this results in the object not being constructed but still queued for finalization.

And I think that this particular example has a twist that makes it even less likely to be fixed. In fact I'd argue that the exhibited behavior is expected:

• Finalizers are NOT destructors. They're basically GC callbacks that are called when the GC determines that the object is dead. That has nothing to do with the object being constructed or not.
• Object allocation and construction are separate affairs. They have to be.
• The twist: the object allocated in this example is not used anywhere, not even in its own constructor. So it's eligible for garbage collection and finalization as soon as it is allocated. Even if the JIT would fix the allocation/arg evaluation order this problem may still randomly occur.

Anyway, if finalization is used as intended this is unlikely to be a real issue.

[peppy]

Thanks for the insight. This is something that wasn't apparently to any of the devs on our team. I guess we have a bit of reading to do.

If this is deemed non-actionable then closing is fine.

[jkotas]

Closing as duplicate dotnet/coreclr#2478

cc @AndyAyersMS