Repository navigation
Test failure JIT\\Regression\\JitBlue\\Runtime_63354\\Runtime_63354\\Runtime_63354.cmd #78898
Copy link
Copy link
Closed
Labels
JitStressCLR JIT issues involving JIT internal stress modesCLR JIT issues involving JIT internal stress modesarch-x86area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMICLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMIblocking-clean-ci-optionalBlocking optional rolling runsBlocking optional rolling runsin-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is mergedos-windows
Milestone
Description
Run: runtime-coreclr jitstress 20221126.2
Failed test:
coreclr windows x86 Checked jitstress1 @ Windows.10.Amd64.Open
- JIT\\Regression\\JitBlue\\Runtime_63354\\Runtime_63354\\Runtime_63354.cmd
coreclr windows x86 Checked jitstress1_tiered @ Windows.10.Amd64.Open
- JIT\\Regression\\JitBlue\\Runtime_63354\\Runtime_63354\\Runtime_63354.cmd
coreclr windows x86 Checked jitstress2 @ Windows.10.Amd64.Open
- JIT\\Regression\\JitBlue\\Runtime_63354\\Runtime_63354\\Runtime_63354.cmd
coreclr windows x86 Checked jitstress2_tiered @ Windows.10.Amd64.Open
- JIT\\Regression\\JitBlue\\Runtime_63354\\Runtime_63354\\Runtime_63354.cmd
Error message:
Assert failure(PID 2576 [0x00000a10], Thread: 5528 [0x1598]): Assertion failed '!m_VariableLiveRanges->back().m_EndEmitLocation.Valid()' in 'Runtime_63354:Test2(System.Numerics.Vector3):System.Numerics.Vector3' during 'Generate code' (IL size 52; hash 0x3273ce14; FullOpts)
File: D:\a\_work\1\s\src\coreclr\jit\codegencommon.cpp Line: 8795
Image: C:\h\w\9B6408B0\p\corerun.exe
Return code: 1
Raw output file: C:\h\w\9B6408B0\w\A9090942\uploads\Reports\JIT.Regression\JitBlue\Runtime_63354\Runtime_63354\Runtime_63354.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\9B6408B0\p\corerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false" Runtime_63354.dll
Expected: 100
Actual: -1073740286
END EXECUTION - FAILED
FAILED
Test Harness Exitcode is : 1
To run the test:
set CORE_ROOT=C:\h\w\9B6408B0\p
C:\h\w\9B6408B0\w\A9090942\e\JIT\Regression\JitBlue\Runtime_63354\Runtime_63354\Runtime_63354.cmd
Expected: True
Actual: False
Stack trace
at JIT_Regression._JitBlue_Runtime_63354_Runtime_63354_Runtime_63354_._JitBlue_Runtime_63354_Runtime_63354_Runtime_63354_cmd()
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
JitStressCLR JIT issues involving JIT internal stress modesCLR JIT issues involving JIT internal stress modesarch-x86area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMICLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMIblocking-clean-ci-optionalBlocking optional rolling runsBlocking optional rolling runsin-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is mergedos-windows
Activity
BruceForstall commentedon Nov 29, 2022
Lots more cases: https://dev.azure.com/dnceng-public/public/_build/results?buildId=94140&view=ms.vss-test-web.build-test-results-tab
BrianBohe commentedon Dec 1, 2022
I bisected this bug. It was introduced on #76491.
BrianBohe commentedon Dec 1, 2022
What is happening is we start a block with V01 arg0 in stack (ebp+08). It is copied to xmm1, indicating live and death. And then reporting the death again of the same variable in xmm1 for a second time without begin alive first.
BrianBohe commentedon Dec 1, 2022
We are reporting a variable as dying in xmm1, although previously saying the same. The first change of liveness happens after HWINSTRINSIC:
where before we modified the variable directly on stack:
SingleAccretion commentedon Dec 1, 2022
It looks suspect to me that
genStoreLclTypeSIMD12does not callgenUpdateLife.BrianBohe commentedon Dec 2, 2022
Calling to genProduceReg (which triggers genUpdateLife) after treenode 39 seems to solved it. What I don't get is, it is a store, and flags indicate it is becoming alive, but we are not updating varDsc with the stack position. It is still there the offset and the lvIsOnFrame set, but the register doesn't change back to STK and keeps XMM1. So reporting life change after that would say v01 is becoming alive in XMM1. The next instruction that triggers the assert is a load from the stack to xmm1 of the same variable, which indicates first it is dying
SingleAccretion commentedon Dec 2, 2022
That also looks like a bug in
genStoreLclTypeSIMD12. It should dovarDsc->SetRegNum(REG_STK);.