ARM32: runtime crash inside JIT

[jakobbotsch]

// Generated by Fuzzlyn v1.2 on 2021-08-07 03:24:16
// Run on .NET 6.0.0-dev on Arm Linux
// Seed: 12756399625466979010
// Reduced from 798.7 KiB to 1.5 KiB in 03:42:20
// Crashes the runtime
struct S0
{
    public bool F0;
    public bool F1;
    public uint F2;
    public short F3;
    public ulong F4;
    public S0(bool f0, bool f1, uint f2, short f3, ulong f4): this()
    {
        F0 = f0;
        F1 = f1;
        F2 = f2;
        F3 = f3;
        F4 = f4;
    }
}

class C0
{
    public C0(S0 f7, S0 f8)
    {
    }
}

class C1
{
    public S0 F1;
    public ulong F5;
}

struct S2
{
    public S2(C0 f4): this()
    {
    }
}

struct S3
{
    public uint F0;
}

class C2
{
    public C1 F3;
}

public class Program
{
    static C2 s_23;
    static C1 s_37;
    static sbyte s_56;
    static S3 s_60;
    public static void Main()
    {
        uint vr2 = default(uint);
        uint vr3;
        bool vr4 = true;
        if (!vr4)
        {
            try
            {
                System.Console.WriteLine(s_60.F0);
            }
            finally
            {
                var vr5 = new C0(new S0(false, true, 0, 0, 0), new S0(false, false, 0, 0, 0));
            }

            s_37.F5 = s_23.F3.F1.F4++;
        }

        vr4 = vr4;
        for (int vr6 = 0; vr6 < 0; vr6++)
        {
            sbyte vr8 = s_56;
            try
            {
                var vr7 = new S2(new C0(new S0(true, false, 0, 0, 0), new S0(true, true, 0, 0, 0)));
            }
            finally
            {
                vr3 = vr2;
            }

            vr3 = vr3;
        }
    }
}

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jakobbotsch]

I'm looking at this.

[jakobbotsch]

The crash happens because the block that contains

s_37.F5 = s_23.F3.F1.F4++;

does not have SSA form built for it; it is unreachable from the entry and thus not part of the dominator tree. Later, we crash here when trying to query SSA information for it during value numbering:

runtime/src/coreclr/jit/optimizer.cpp

Lines 7247 to 7250 in f02d9ff

	if (lvaInSsa(argLcl->GetLclNum()))
	{
	ValueNum argVN =
	lvaTable[argLcl->GetLclNum()].GetPerSsaData(argLcl->GetSsaNum())->m_vnPair.GetLiberal();

That's kind of strange, since that code runs only for IR nodes inside loops, and the snippet above is not inside a loop. However, in ARM32 the flow-graph is a little different due to different exception handling blocks being added compared to other platforms and then fgReorderBlocks ends up reordering blocks so that the loop spans the unreachable block. I believe we would see similar crashes for other platforms if we somehow could produce a natural loop that contained the snippet above (I tried but was unable to due to various heuristics/checks blocking it).

Not totally sure how to fix this. It's weird that we have this unreachable code sticking around, but that seems to be a consequence of the exception handlers inside the block and also seems to happen on other platforms (at least x86). Perhaps we should just be checking if the local has SSA form built for it in the value numbering code? Though it seems unfortunate to have to handle this case downstream.

cc @dotnet/jit-contrib

[jakobbotsch]

In x64 we do seem to be able to remove that unreachable block entirely, so not completely sure why it is left over in x86/ARM32.

[jakobbotsch]

That seems to be a bug in fgRemoveUnreachableBlocks. When we "remove" a block that has BBF_DONT_REMOVE set, we set it as BBJ_THROW instead of removing it from the flow-graph. However, fgRemoveUnreachableBlocks only returns true if unreachable blocks are actually removed. In x86 and ARM32 there is only one unreachable block in the first iteration, and it is marked BBF_DONT_REMOVE, so we don't try to see if there are more unreachable blocks after the first iteration. In x64 we import more blocks and the first iteration removes one of these blocks (in addition to marking another as BBJ_THROW), so the loop runs again.