Test failure: Regressions/coreclr/0582/csgen.1/csgen.1.cmd #102296

v-wenyuxu · 2024-05-16T01:44:10Z

Failed in: runtime-coreclr jitstress2-jitstressregs 20240515.1

Failed tests:

coreclr windows x86 Checked jitstress2_jitstressregs0x80 @ Windows.10.Amd64.Open
    - Regressions/coreclr/0582/csgen.1/csgen.1.cmd

Error message:

 
Assert failure(PID 448 [0x000001c0], Thread: 1248 [0x04e0]): Assertion failed 'false && !"Mismatch in align instruction"' in 'BB:Static1(double[,,][],byref,int,byref)' during 'Generate code' (IL size 368; hash 0xadca06fd; FullOpts)

    File: D:�_work1ssrccoreclrjitemit.cpp:5931
    Image: C:hwA0520956pcorerun.exe


Return code:      1
Raw output file:      C:hwA0520956wB96709D5uploadscoreclr
Raw output:
BEGIN EXECUTION
 "C:hwA0520956pcorerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false" -p "System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization=true"  csgen.1.dll 


Mismatch in align instruction.
Containing IG: IG06
loopHeadPredIG: IG83
loopHeadIG: IG84
igInLoop: IG87
igInLoop->igLoopBackEdge: IG85
igInLoop has align instruction for : IG88
Loop:
	IG84
	IG85
	IG86
	IG87
	IG88
	IG89
	IG90
	IG91
	IG92
	IG93
	IG94
	IG95
	IG96
	IG97
	IG98
	IG99
	IG100
	IG101
	IG102
	IG103
	IG104
	IG105
	IG106
	IG107
	IG108
	IG109
	IG110
	IG111
	IG112
	IG113
	IG114
	IG115
	IG116
	IG117
	IG118
	IG119
	IG120
	IG121
	IG122
Did not find IG with back edge to IG84
Expected: 100
Actual: -1073740286
END EXECUTION - FAILED
FAILED
Test failed. Trying to see if dump file was created in C:cores since 5/15/2024 5:31:48 PM
Processing C:corescorerun.exe.448.dmp
Invoking: C:Program Files (x86)Windows Kits10Debuggers�cdb.exe -c "$<C:hwA0520956		mpcgadsn.tmp" -z "C:corescorerun.exe.448.dmp"
stdout: 
Microsoft (R) Windows Debugger Version 10.0.18362.1 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:corescorerun.exe.448.dmp]
User Mini Dump File with Full Memory: Only application data is available


************* Path validation summary **************
Response                         Time (ms)     Location
OK                                             C:hwA0520956pPDB
Symbol search path is: C:hwA0520956pPDB
Executable search path is: 
Windows 10 Version 14393 MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer DataCenter SingleUserTS
10.0.14393.6343 (rs1_release.230913-1727)
Machine Name:
Debug session time: Wed May 15 17:31:51.000 2024 (UTC + 0:00)
System Uptime: 0 days 2:09:03.866
Process Uptime: 0 days 0:00:03.000
.............................

************* Symbol Loading Error Summary **************
Module name            Error
ntdll                  The system cannot find the file specified

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1c0.4e0): Unknown exception - code c0000602 (first/second chance not available)
For analysis of this file, run !analyze -v
*** WARNING: Unable to verify checksum for coreclr.dll
eax=00b78478 ebx=00000000 ecx=00000000 edx=00000000 esi=00b78428 edi=00b78478
eip=72155c9c esp=00b7875c ebp=00b797f4 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
coreclr!FailFastOnAssert+0x21:
72155c9c 5e              pop     esi
0:000> cdb: Reading initial command '$<C:hwA0520956		mpcgadsn.tmp'
0:000> .load C:Users
unner.dotnetsossos.dll
0:000> ~*k

.  0  Id: 1c0.4e0 Suspend: 0 Teb: 00824000 Unfrozen
ChildEBP RetAddr  
00b78768 72156978 coreclr!FailFastOnAssert+0x21
00b797f4 71d1aa48 coreclr!_DbgBreakCheck+0x337
*** WARNING: Unable to verify checksum for clrjit.dll
00b7985c 7058d13e coreclr!CEEInfo::doAssert+0x68
00b7b890 7058c295 clrjit!assertAbort+0xd8
00b7cc50 70584169 clrjit!emitter::getLoopSize+0x238
00b7cc8c 70589304 clrjit!emitter::emitCalculatePaddingForLoopAlignment+0x81
00b7cce8 70567a60 clrjit!emitter::emitLoopAlignAdjustments+0x1bb
00b7ccf8 70563304 clrjit!CodeGen::genGenerateMachineCode+0x360
00b7cd04 7068a228 clrjit!CodeGenPhase::DoPhase+0x14
00b7cd

Stack trace:

   at Xunit.Assert.True(Nullable`1 condition, String userMessage) in /_/src/Microsoft.DotNet.XUnitAssert/src/BooleanAsserts.cs:line 146
   at Xunit.Assert.True(Boolean condition, String userMessage) in /_/src/Microsoft.DotNet.XUnitAssert/src/BooleanAsserts.cs:line 128
   at TestLibrary.OutOfProcessTest.RunOutOfProcessTest(String assemblyPath, String testPathPrefix)
   at Program.<<Main>$>g__TestExecutor11|0_12(StreamWriter tempLogSw, StreamWriter statsCsvSw, <>c__DisplayClass0_0&)

The text was updated successfully, but these errors were encountered:

dotnet-policy-service · 2024-05-16T01:44:32Z

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

JulieLeeMSFT · 2024-05-16T21:52:18Z

@TIHan, PTAL.

v-wenyuxu · 2024-05-20T01:42:36Z

Failed in: runtime-coreclr jitstress2-jitstressregs 20240519.1

Failed tests:

coreclr windows x86 Checked jitstress2_jitstressregs0x80 @ Windows.10.Amd64.Open
    - Regressions/coreclr/0582/csgen.1/csgen.1.cmd

Error message:

 
Assert failure(PID 5016 [0x00001398], Thread: 3008 [0x0bc0]): Assertion failed 'false && !"Mismatch in align instruction"' in 'BB:Static1(double[,,][],byref,int,byref)' during 'Generate code' (IL size 368; hash 0xadca06fd; FullOpts)

    File: D:�_work1ssrccoreclrjitemit.cpp:5931
    Image: C:hwAECB099Cpcorerun.exe


Return code:      1
Raw output file:      C:hwAECB099CwB26509ADuploadscoreclr
Raw output:
BEGIN EXECUTION
 "C:hwAECB099Cpcorerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false" -p "System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization=true"  csgen.1.dll 


Mismatch in align instruction.
Containing IG: IG06
loopHeadPredIG: IG83
loopHeadIG: IG84
igInLoop: IG87
igInLoop->igLoopBackEdge: IG85
igInLoop has align instruction for : IG88
Loop:
	IG84
	IG85
	IG86
	IG87
	IG88
	IG89
	IG90
	IG91
	IG92
	IG93
	IG94
	IG95
	IG96
	IG97
	IG98
	IG99
	IG100
	IG101
	IG102
	IG103
	IG104
	IG105
	IG106
	IG107
	IG108
	IG109
	IG110
	IG111
	IG112
	IG113
	IG114
	IG115
	IG116
	IG117
	IG118
	IG119
	IG120
	IG121
	IG122
Did not find IG with back edge to IG84
Expected: 100
Actual: -1073740286
END EXECUTION - FAILED
FAILED
Test failed. Trying to see if dump file was created in C:cores since 5/19/2024 7:01:48 PM
Processing C:corescorerun.exe.5016.dmp
Invoking: C:Program Files (x86)Windows Kits10Debuggers�cdb.exe -c "$<C:hwAECB099C		mp3h5ek3.tmp" -z "C:corescorerun.exe.5016.dmp"
stdout: 
Microsoft (R) Windows Debugger Version 10.0.18362.1 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:corescorerun.exe.5016.dmp]
User Mini Dump File with Full Memory: Only application data is available


************* Path validation summary **************
Response                         Time (ms)     Location
OK                                             C:hwAECB099CpPDB
Symbol search path is: C:hwAECB099CpPDB
Executable search path is: 
Windows 10 Version 14393 MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer DataCenter SingleUserTS
10.0.14393.6343 (rs1_release.230913-1727)
Machine Name:
Debug session time: Sun May 19 19:01:49.000 2024 (UTC + 0:00)
System Uptime: 0 days 2:14:28.506
Process Uptime: 0 days 0:00:01.000
.............................

************* Symbol Loading Error Summary **************
Module name            Error
ntdll                  The system cannot find the file specified

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1398.bc0): Unknown exception - code c0000602 (first/second chance not available)
For analysis of this file, run !analyze -v
*** WARNING: Unable to verify checksum for coreclr.dll
eax=031d81d8 ebx=00000000 ecx=00000000 edx=00000000 esi=031d8188 edi=031d81d8
eip=7219f0ea esp=031d84bc ebp=031d9554 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
coreclr!FailFastOnAssert+0x21:
7219f0ea 5e              pop     esi
0:000> cdb: Reading initial command '$<C:hwAECB099C		mp3h5ek3.tmp'
0:000> .load C:Users
unner.dotnetsossos.dll
0:000> ~*k

.  0  Id: 1398.bc0 Suspend: 0 Teb: 02e67000 Unfrozen
ChildEBP RetAddr  
031d84c8 7219fe5a coreclr!FailFastOnAssert+0x21
031d9554 71d5ba48 coreclr!_DbgBreakCheck+0x337
*** WARNING: Unable to verify checksum for clrjit.dll
031d95bc 705bd14e coreclr!CEEInfo::doAssert+0x68
031db5f0 705bc2a5 clrjit!assertAbort+0xd8
031dc9b0 705b4179 clrjit!emitter::getLoopSize+0x238
031dc9ec 705b9314 clrjit!emitter::emitCalculatePaddingForLoopAlignment+0x81
031dca48 70597a70 clrjit!emitter::emitLoopAlignAdjustments+0x1bb
031dca58 70593314 clrjit!CodeGen::genGenerateMachineCode+0x360
031dca64 706ba6d8 clrjit!CodeGenPhase::DoPhase+0x14

Stack trace:

   at Xunit.Assert.True(Nullable`1 condition, String userMessage) in /_/src/Microsoft.DotNet.XUnitAssert/src/BooleanAsserts.cs:line 146
   at Xunit.Assert.True(Boolean condition, String userMessage) in /_/src/Microsoft.DotNet.XUnitAssert/src/BooleanAsserts.cs:line 128
   at TestLibrary.OutOfProcessTest.RunOutOfProcessTest(String assemblyPath, String testPathPrefix)
   at Program.<<Main>$>g__TestExecutor11|0_12(StreamWriter tempLogSw, StreamWriter statsCsvSw, <>c__DisplayClass0_0&)

v-wenyuxu · 2024-05-22T01:41:44Z

Failed in: runtime-coreclr jitstress2-jitstressregs 20240521.1

Failed tests:

coreclr windows x86 Checked jitstress2_jitstressregs0x80 @ Windows.10.Amd64.Open
    - Regressions/coreclr/0582/csgen.1/csgen.1.cmd

Error message:

 
Assert failure(PID 8116 [0x00001fb4], Thread: 9944 [0x26d8]): Assertion failed 'false && !"Mismatch in align instruction"' in 'BB:Static1(double[,,][],byref,int,byref)' during 'Generate code' (IL size 343; hash 0xadca06fd; FullOpts)

    File: D:�_work1ssrccoreclrjitemit.cpp:5931
    Image: C:hwA4D7096Fpcorerun.exe


Return code:      1
Raw output file:      C:hwA4D7096FwB7420998uploadscoreclr
Raw output:
BEGIN EXECUTION
 "C:hwA4D7096Fpcorerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false" -p "System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization=true"  csgen.1.dll 


Mismatch in align instruction.
Containing IG: IG06
loopHeadPredIG: IG83
loopHeadIG: IG84
igInLoop: IG87
igInLoop->igLoopBackEdge: IG85
igInLoop has align instruction for : IG88
Loop:
	IG84
	IG85
	IG86
	IG87
	IG88
	IG89
	IG90
	IG91
	IG92
	IG93
	IG94
	IG95
	IG96
	IG97
	IG98
	IG99
	IG100
	IG101
	IG102
	IG103
	IG104
	IG105
	IG106
	IG107
	IG108
	IG109
	IG110
	IG111
	IG112
	IG113
	IG114
	IG115
	IG116
	IG117
	IG118
	IG119
	IG120
	IG121
	IG122
Did not find IG with back edge to IG84
Expected: 100
Actual: -1073740286
END EXECUTION - FAILED
FAILED
Test failed. Trying to see if dump file was created in C:cores since 5/21/2024 10:12:33 PM
Processing C:corescorerun.exe.8116.dmp
Invoking: C:Program Files (x86)Windows Kits10Debuggers�cdb.exe -c "$<C:hwA4D7096F		mp3whfra.tmp" -z "C:corescorerun.exe.8116.dmp"
stdout: 
Microsoft (R) Windows Debugger Version 10.0.18362.1 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:corescorerun.exe.8116.dmp]
User Mini Dump File with Full Memory: Only application data is available


************* Path validation summary **************
Response                         Time (ms)     Location
OK                                             C:hwA4D7096FpPDB
Symbol search path is: C:hwA4D7096FpPDB
Executable search path is: 
Windows 10 Version 14393 MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer DataCenter SingleUserTS
10.0.14393.6343 (rs1_release.230913-1727)
Machine Name:
Debug session time: Tue May 21 22:12:38.000 2024 (UTC + 0:00)
System Uptime: 0 days 1:16:59.228
Process Uptime: 0 days 0:00:04.000
.............................

************* Symbol Loading Error Summary **************
Module name            Error
ntdll                  The system cannot find the file specified

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1fb4.26d8): Unknown exception - code c0000602 (first/second chance not available)
For analysis of this file, run !analyze -v
*** WARNING: Unable to verify checksum for coreclr.dll
eax=00778288 ebx=00000000 ecx=00000000 edx=00000000 esi=00778238 edi=00778288
eip=726af170 esp=0077856c ebp=00779604 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
coreclr!FailFastOnAssert+0x21:
726af170 5e              pop     esi
0:000> cdb: Reading initial command '$<C:hwA4D7096F		mp3whfra.tmp'
0:000> .load C:Users
unner.dotnetsossos.dll
0:000> ~*k

.  0  Id: 1fb4.26d8 Suspend: 0 Teb: 0043a000 Unfrozen
ChildEBP RetAddr  
00778578 726afee0 coreclr!FailFastOnAssert+0x21
00779604 7226ba48 coreclr!_DbgBreakCheck+0x337
*** WARNING: Unable to verify checksum for clrjit.dll
0077966c 70add14e coreclr!CEEInfo::doAssert+0x68
0077b6a0 70adc2a5 clrjit!assertAbort+0xd8
0077ca60 70ad4179 clrjit!emitter::getLoopSize+0x238
0077ca9c 70ad9314 clrjit!emitter::emitCalculatePaddingForLoopAlignment+0x81
0077caf8 70ab7a70 clrjit!emitter::emitLoopAlignAdjustments+0x1bb
0077cb08 70ab3314 clrjit!CodeGen::genGenerateMachineCode+0x360
0077cb14 70bda9a8 clrjit!CodeGenPhase::DoPhase+0x

Stack trace:

   at Xunit.Assert.True(Nullable`1 condition, String userMessage) in /_/src/Microsoft.DotNet.XUnitAssert/src/BooleanAsserts.cs:line 146
   at Xunit.Assert.True(Boolean condition, String userMessage) in /_/src/Microsoft.DotNet.XUnitAssert/src/BooleanAsserts.cs:line 128
   at TestLibrary.OutOfProcessTest.RunOutOfProcessTest(String assemblyPath, String testPathPrefix)
   at Program.<<Main>$>g__TestExecutor11|0_12(StreamWriter tempLogSw, StreamWriter statsCsvSw, <>c__DisplayClass0_0&)

TIHan · 2024-05-22T22:58:10Z

I'm able to reproduce the assertion, will be looking into it.

TIHan · 2024-05-23T02:35:33Z

Assertion first starts appearing after #101894 but doesn't look like the change caused this assertion.

Here are the dumps from before and after the change.
dump_before.txt
dump_after.txt

TIHan · 2024-05-24T01:04:14Z

@kunalspathak and I went through this one for several hours, it's not trivial. I'll sum up what we learned.

Why does the assertion occur?

When validating loop alignment, the align instruction's loop header IG does not match the loop back edge IG.

Mismatch in align instruction.
Containing IG: IG06
loopHeadPredIG: IG83
loopHeadIG: IG84
igInLoop: IG87
igInLoop->igLoopBackEdge: IG85
igInLoop has align instruction for : IG88

Notice loopHeadIG: IG84 and igInLoop->igLoopBackEdge: IG85. These should be identical, either IG84 or IG85 - we don't know yet.

Why are `loopHeadIG` and `igLoopBackEdge` different?

loopHeadIG is set to IG84 by emitConnectAlignInstrWithCurIG(). At this point, IG84 does not have any instructions.

Later on, the block that holds IG84, its bbEmitCookie gets set via emitAddLabel:

        if (needLabel)
        {
            // Mark a label and update the current set of live GC refs

            block->bbEmitCookie = GetEmitter()->emitAddLabel(gcInfo.gcVarPtrSetCur, gcInfo.gcRegGCrefSetCur,
                                                             gcInfo.gcRegByrefSetCur, block->Prev());

The result from emitAddLabel is IG85, which means the bbEmitCookie is now set to IG85.
The bbEmitCookie is used to set igLoopBackEdge. This explains why loopHeadIG and igLoopBackEdge are not the same.

Why does `emitAddLabel` return `IG85`?

When we call emitAddLabel, the current IG is IG84 with no instructions.
However, emitAddLabel handles a special GC case:

    // if starting a new block that can be a target of a branch and the last instruction was GC-capable call.
    if ((prevBlock != nullptr) && emitComp->compCurBB->HasFlag(BBF_HAS_LABEL) && emitLastInsIsCallWithGC())
    {
        // no GC-capable calls expected in prolog
        assert(!emitIGisInEpilog(emitLastInsIG));

        // We have just emitted a call that can do GC and conservatively recorded what is alive after the call.
        // Now we see that the next instruction may be reachable by a branch with a different liveness.
        // We want to maintain the invariant that the GC info at IP after a GC-capable call is the same
        // regardless how it is reached.
        // One way to ensure that is by adding an instruction (NOP or BRK) after the call.
        if ((emitThisGCrefRegs != gcrefRegs) || (emitThisByrefRegs != byrefRegs) ||
            !VarSetOps::Equal(emitComp, emitThisGCrefVars, GCvars))
        {
            if (prevBlock->KindIs(BBJ_THROW))
            {
                emitIns(INS_BREAKPOINT);
            }
            else
            {
                // other block kinds should emit something at the end that is not a call.
                assert(prevBlock->KindIs(BBJ_ALWAYS));
                // CONSIDER: In many cases we could instead patch up the GC info for previous call instruction.
                emitIns(INS_nop);
            }
        }
    }

For this scenario, the emitIns(INS_nop); will be hit and now IG84 has one instruction, nop.
Because IG84 has an instruction, a new IG has to be created:

    /* Create a new IG if the current one is non-empty */

    if (emitCurIGnonEmpty())
    {
        emitNxtIG();
    }

This is where IG85 is created and is now the current IG, which gets returned from emitAddLabel.

What can we do?

@kunalspathak and I will be looking into this more. We do not know yet what the behavior should be when this happens. Do we update the align instruction's loopHeadIG with IG85? Or do we just bail on alignment in this very rare case?

v-wenyuxu · 2024-05-27T01:32:46Z

Failed in: runtime-coreclr jitstress2-jitstressregs 20240526.1

Failed tests:

coreclr windows x86 Checked jitstress2_jitstressregs0x80 @ Windows.10.Amd64.Open
    - Regressions/coreclr/0582/csgen.1/csgen.1.cmd

Error message:

 
Assert failure(PID 3256 [0x00000cb8], Thread: 1116 [0x045c]): Assertion failed 'false && !"Mismatch in align instruction"' in 'BB:Static1(double[,,][],byref,int,byref)' during 'Generate code' (IL size 343; hash 0xadca06fd; FullOpts)

    File: D:�_work1ssrccoreclrjitemit.cpp:5931
    Image: C:hwAE1A0919pcorerun.exe


Return code:      1
Raw output file:      C:hwAE1A0919wB5700A30uploadscoreclr
Raw output:
BEGIN EXECUTION
 "C:hwAE1A0919pcorerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false" -p "System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization=true"  csgen.1.dll 


Mismatch in align instruction.
Containing IG: IG52
loopHeadPredIG: IG86
loopHeadIG: IG87
igInLoop: IG90
igInLoop->igLoopBackEdge: IG88
igInLoop has align instruction for : IG91
Loop:
	IG87
	IG88
	IG89
	IG90
	IG91
	IG92
	IG93
	IG94
	IG95
	IG96
	IG97
	IG98
	IG99
	IG100
	IG101
	IG102
	IG103
	IG104
	IG105
	IG106
	IG107
	IG108
	IG109
	IG110
	IG111
	IG112
	IG113
	IG114
	IG115
	IG116
	IG117
	IG118
	IG119
	IG120
	IG121
	IG122
Did not find IG with back edge to IG87
Expected: 100
Actual: -1073740286
END EXECUTION - FAILED
FAILED
Test failed. Trying to see if dump file was created in C:cores since 5/26/2024 6:53:53 PM
Processing C:corescorerun.exe.3256.dmp
Invoking: C:Program Files (x86)Windows Kits10Debuggers�cdb.exe -c "$<C:hwAE1A0919		mptu5pzw.tmp" -z "C:corescorerun.exe.3256.dmp"
stdout: 
Microsoft (R) Windows Debugger Version 10.0.18362.1 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:corescorerun.exe.3256.dmp]
User Mini Dump File with Full Memory: Only application data is available


************* Path validation summary **************
Response                         Time (ms)     Location
OK                                             C:hwAE1A0919pPDB
Symbol search path is: C:hwAE1A0919pPDB
Executable search path is: 
Windows 10 Version 14393 MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer DataCenter SingleUserTS
10.0.14393.6343 (rs1_release.230913-1727)
Machine Name:
Debug session time: Sun May 26 18:53:58.000 2024 (UTC + 0:00)
System Uptime: 0 days 0:08:59.094
Process Uptime: 0 days 0:00:05.000
.............................

************* Symbol Loading Error Summary **************
Module name            Error
ntdll                  The system cannot find the file specified

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(cb8.45c): Unknown exception - code c0000602 (first/second chance not available)
For analysis of this file, run !analyze -v
*** WARNING: Unable to verify checksum for coreclr.dll
eax=01378308 ebx=00000000 ecx=00000000 edx=00000000 esi=013782b8 edi=01378308
eip=7266a69d esp=013785ec ebp=01379684 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
coreclr!FailFastOnAssert+0x21:
7266a69d 5e              pop     esi
0:000> cdb: Reading initial command '$<C:hwAE1A0919		mptu5pzw.tmp'
0:000> .load C:Users
unner.dotnetsossos.dll
0:000> ~*k

.  0  Id: cb8.45c Suspend: 0 Teb: 0112f000 Unfrozen
ChildEBP RetAddr  
013785f8 7266b40d coreclr!FailFastOnAssert+0x21
01379684 72226618 coreclr!_DbgBreakCheck+0x337
*** WARNING: Unable to verify checksum for clrjit.dll
013796ec 70abd36e coreclr!CEEInfo::doAssert+0x68
0137b720 70abc4ca clrjit!assertAbort+0xd8
0137cae0 70ab431a clrjit!emitter::getLoopSize+0x238
0137cb1c 70ab9509 clrjit!emitter::emitCalculatePaddingForLoopAlignment+0x81
0137cb78 70a97b80 clrjit!emitter::emitLoopAlignAdjustments+0x1bb
0137cb88 70a93334 clrjit!CodeGen::genGenerateMachineCode+0x360
0137cb94 70bbb1b8 clrjit!CodeGenPhase::DoPhase+0x14
0137cbc8 70a97788 cl

Stack trace:

   at Xunit.Assert.True(Nullable`1 condition, String userMessage) in /_/src/Microsoft.DotNet.XUnitAssert/src/BooleanAsserts.cs:line 146
   at Xunit.Assert.True(Boolean condition, String userMessage) in /_/src/Microsoft.DotNet.XUnitAssert/src/BooleanAsserts.cs:line 128
   at TestLibrary.OutOfProcessTest.RunOutOfProcessTest(String assemblyPath, String testPathPrefix)
   at Program.<<Main>$>g__TestExecutor11|0_12(StreamWriter tempLogSw, StreamWriter statsCsvSw, <>c__DisplayClass0_0&)

jakobbotsch · 2024-05-29T08:20:06Z

However, emitAddLabel handles a special GC case:

    // if starting a new block that can be a target of a branch and the last instruction was GC-capable call.
    if ((prevBlock != nullptr) && emitComp->compCurBB->HasFlag(BBF_HAS_LABEL) && emitLastInsIsCallWithGC())
    {
        // no GC-capable calls expected in prolog
        assert(!emitIGisInEpilog(emitLastInsIG));

        // We have just emitted a call that can do GC and conservatively recorded what is alive after the call.
        // Now we see that the next instruction may be reachable by a branch with a different liveness.
        // We want to maintain the invariant that the GC info at IP after a GC-capable call is the same
        // regardless how it is reached.
        // One way to ensure that is by adding an instruction (NOP or BRK) after the call.
        if ((emitThisGCrefRegs != gcrefRegs) || (emitThisByrefRegs != byrefRegs) ||
            !VarSetOps::Equal(emitComp, emitThisGCrefVars, GCvars))
        {
            if (prevBlock->KindIs(BBJ_THROW))
            {
                emitIns(INS_BREAKPOINT);
            }
            else
            {
                // other block kinds should emit something at the end that is not a call.
                assert(prevBlock->KindIs(BBJ_ALWAYS));
                // CONSIDER: In many cases we could instead patch up the GC info for previous call instruction.
                emitIns(INS_nop);
            }
        }
    }

For this scenario, the emitIns(INS_nop); will be hit and now IG84 has one instruction, nop.

This code was added by #95565. I do wonder why we didn't see the failures as part of that PR.

v-wenyuxu added arch-x86 os-windows JitStress CLR JIT issues involving JIT internal stress modes area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI blocking-clean-ci-optional Blocking optional rolling runs labels May 16, 2024

dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label May 16, 2024

JulieLeeMSFT added this to the 9.0.0 milestone May 16, 2024

JulieLeeMSFT assigned TIHan May 16, 2024

JulieLeeMSFT removed the untriaged New issue has not been triaged by the area owner label May 16, 2024

This was referenced May 28, 2024

JIT: Connect align instruction after a label gets possibly added #102789

Closed

JIT: Disable test csgen.1 for windows x86 #102794

Merged

TIHan closed this as completed in #102794 May 29, 2024

github-actions bot locked and limited conversation to collaborators Jun 28, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Test failure: Regressions/coreclr/0582/csgen.1/csgen.1.cmd #102296

Test failure: Regressions/coreclr/0582/csgen.1/csgen.1.cmd #102296

v-wenyuxu commented May 16, 2024

dotnet-policy-service bot commented May 16, 2024

JulieLeeMSFT commented May 16, 2024

v-wenyuxu commented May 20, 2024

v-wenyuxu commented May 22, 2024

TIHan commented May 22, 2024

TIHan commented May 23, 2024 •

edited

Loading

TIHan commented May 24, 2024

v-wenyuxu commented May 27, 2024

jakobbotsch commented May 29, 2024

Test failure: Regressions/coreclr/0582/csgen.1/csgen.1.cmd #102296

Test failure: Regressions/coreclr/0582/csgen.1/csgen.1.cmd #102296

Comments

v-wenyuxu commented May 16, 2024

dotnet-policy-service bot commented May 16, 2024

JulieLeeMSFT commented May 16, 2024

v-wenyuxu commented May 20, 2024

v-wenyuxu commented May 22, 2024

TIHan commented May 22, 2024

TIHan commented May 23, 2024 • edited Loading

TIHan commented May 24, 2024

Why does the assertion occur?

Why are loopHeadIG and igLoopBackEdge different?

Why does emitAddLabel return IG85?

What can we do?

v-wenyuxu commented May 27, 2024

jakobbotsch commented May 29, 2024

TIHan commented May 23, 2024 •

edited

Loading

Why are `loopHeadIG` and `igLoopBackEdge` different?

Why does `emitAddLabel` return `IG85`?