Test failure: JIT/Regression/JitBlue/Runtime_65937/Runtime_65937/Runtime_65937.dll

[BruceForstall]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=302664&view=ms.vss-test-web.build-test-results-tab&runId=6137580&paneView=debug

coreclr linux x64 Checked jitstress_isas_nohwintrinsic @ Ubuntu.1804.Amd64.Open

21:13:50.174 Running test: JIT/Regression/JitBlue/Runtime_65937/Runtime_65937/Runtime_65937.dll
Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at Runtime_65937.TestEntryPoint()
   at Program.<<Main>$>g__TestExecutor222|0_223(System.IO.StreamWriter, System.IO.StreamWriter, <>c__DisplayClass0_0 ByRef)
   at Program.<Main>$(System.String[])

export DOTNET_TieredCompilation=0
export DOTNET_EnableHWIntrinsic=0

@dotnet/jit-contrib

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

Issue Details

---

https://dev.azure.com/dnceng-public/public/_build/results?buildId=302664&view=ms.vss-test-web.build-test-results-tab&runId=6137580&paneView=debug

coreclr linux x64 Checked jitstress_isas_nohwintrinsic @ Ubuntu.1804.Amd64.Open

21:13:50.174 Running test: JIT/Regression/JitBlue/Runtime_65937/Runtime_65937/Runtime_65937.dll
Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at Runtime_65937.TestEntryPoint()
   at Program.<<Main>$>g__TestExecutor222|0_223(System.IO.StreamWriter, System.IO.StreamWriter, <>c__DisplayClass0_0 ByRef)
   at Program.<Main>$(System.String[])

export DOTNET_TieredCompilation=0
export DOTNET_EnableHWIntrinsic=0

@dotnet/jit-contrib

Author:	BruceForstall
Assignees:	-
Labels:	JitStress, area-CodeGen-coreclr, blocking-clean-ci-optional
Milestone:	8.0.0

[EgorBo]

Crashes on

->  0x7fff79479af1: rep    movsb        (%rsi), %es:(%rdi)

rings a bell to anyone?

[EgorBo]

cc @jakobbotsch smells like some struct PR, e.g.:

static void test(byte* pages)
{
    CallWithStkArg(0, 0, 0, 0, 0, 0, *(StructWithNineBytes*)(pages + 0x1000 - sizeof(StructWithNineBytes)));
}

codegen diff: https://www.diffchecker.com/hblePSaj/

The right one has DOTNET_EnableHWIntrinsic=0 and is crashed on rep movsb

[tannergooding]

Is RCX potentially misinitialized here and its reading/writing too much?

Edit: Looks like it is based on the diff, the left is reading/writing 9-bytes (8 + 1), the right is reading/writing 16-bytes

[jakobbotsch]

My bisection gives af1262c, before that we generate

       lea      rdi, [r14+0FF7H]
       mov      rsi, qword ptr [rdi]
       mov      qword ptr [rsp], rsi
       mov      sil, byte  ptr [rdi+08H]
       mov      byte  ptr [rsp+08H], sil

for the copy:

 N003 (  3,  6) [000013] -----------                   t13 = ▌  ADD       long   $180
                                                             ┌──▌  t13    long   
 N004 (  9, 10) [000017] -c-XG------                   t17 = ▌  BLK       struct<Runtime_65937+StructWithNineBytes, 9> <l:$280, c:$281>
                                                             ┌──▌  t17    struct 
-               [000054] ---XG------                         ▌  PUTARG_STK [+0x00] void   (16 stackByteSize), (0 byteOffset) (Unroll)
+               [000054] ---XG------                         ▌  PUTARG_STK [+0x00] void   (16 stackByteSize), (0 byteOffset) (RepInstr)

[SingleAccretion]

The nominal bug is in genConsumePutStructArgStk (it uses the padded size of the argument as the size to load) and appears quite old, presumably af1262c exposed it in some way.

[tannergooding]

The most likely related change in af1262c was simply one such that we would correctly return 0 for getVectorTByteLength() and getMaxVectorByteLength() if there the relevant ISAs were not present.

This issue is probably being exposed by the latter returning 0 when SSE is disabled and therefore forcing it down the existing fallback path (e.g. the same path we'd be executing on x86 Unix).

[tannergooding]

Closing in favor of #87502 worked around by #87420