JIT: Assertion failed '!fgRngChkThrowAdded'

[BruceForstall]

// Generated by Fuzzlyn v2.7 on 2025-04-24 00:38:43
// Run on X64 Windows
// Seed: 101084439064447232-vectort,vector128,vector256,vector512,x86aes,x86avx,x86avx2,x86avx512bw,x86avx512bwvl,x86avx512cd,x86avx512cdvl,x86avx512dq,x86avx512dqvl,x86avx512f,x86avx512fvl,x86avx512fx64,x86avx512vbmi,x86avx512vbmivl,x86bmi1,x86bmi1x64,x86bmi2,x86bmi2x64,x86fma,x86lzcnt,x86lzcntx64,x86pclmulqdq,x86popcnt,x86popcntx64,x86sse,x86ssex64,x86sse2,x86sse2x64,x86sse3,x86sse41,x86sse41x64,x86sse42,x86sse42x64,x86ssse3,x86x86base
// Reduced from 125.5 KiB to 0.6 KiB in 00:01:32
// Hits JIT assert in Release:
// Assertion failed '!fgRngChkThrowAdded' in 'Program:Main(Fuzzlyn.ExecutionServer.IRuntime)' during 'Calculate stack level slots' (IL size 68; hash 0xade6b36b; FullOpts)
// 
//     File: C:\gh\runtime\src\coreclr\jit\flowgraph.cpp Line: 3754
// 
using System;
using System.Numerics;
using System.Runtime.Intrinsics;
using System.Runtime.Intrinsics.X86;

public class Program
{
    public static bool[] s_31;
    public static void Main()
    {
        byte vr11 = default(byte);
        byte[] vr12 = new byte[]
        {
            0
        };
        try
        {
            vr12[0] = vr12[0];
        }
        catch (System.Exception)
        {
        }

        try
        {
            System.Console.WriteLine(vr11);
        }
        catch (System.Exception)when (s_31[0])
        {
        }
    }
}

@dotnet/jit-contrib

[dotnet-policy-service]

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

[EgorBo]

looks like the issue is in fgRemoveEmptyTryCatchOrTryFault

[EgorBo]

@AndyAyersMS does it ring a bell to you? it seems like late try-catch removal (PHASE_EMPTY_TRY_CATCH_FAULT_3) removes an EH region (0) and messes up with fgAddCodeDscMap cache so we no longer can find an entry for BB8 + RNGCHK_FAIL pair (seems like lookup is based on bbTryIndex and bbHndIndex and previously BB8 was in EH region 1, now in 0) - perhaps, the bug is in fgUpdateACDsBeforeEHTableEntryRemoval

[AndyAyersMS]

@AndyAyersMS does it ring a bell to you? it seems like late try-catch removal (PHASE_EMPTY_TRY_CATCH_FAULT_3) removes an EH region (0) and messes up with fgAddCodeDscMap cache so we no longer can find an entry for BB8 + RNGCHK_FAIL pair (seems like lookup is based on bbTryIndex and bbHndIndex and previously BB8 was in EH region 1, now in 0) - perhaps, the bug is in fgUpdateACDsBeforeEHTableEntryRemoval

Yeah if we mess up the ACDs it could lead to this error. I can take a look.

[AndyAyersMS]

Is there some special config needed to repro this?

[EgorBo]

Is there some special config needed to repro this?

@AndyAyersMS repoes for me as is on Main with Checked JIT and TC=0, I just run it and it hits an assert

[AndyAyersMS]

Is there some special config needed to repro this?

@AndyAyersMS repoes for me as is on Main with Checked JIT and TC=0, I just run it and it hits an assert

Looks like I was using an older build, I can repro now.

[AndyAyersMS]

This test has a filter-inspired ACD, looks like we don't update those properly.

[BruceForstall]

Fixed by #115054