x86 gcstress 0xC zapdisable heapverify1 failures

[AndyAyersMS]

Forking from dotnet/coreclr#17330.

JIT_Methodical._ELEMENT_TYPE_IU__il_dbgu_fld
JIT_Methodical._ELEMENT_TYPE_IU__il_relu_fld

Example runs with failures: 14, 15

Haven't been able to repro these locally. Failure is just a bogus return code with no other indication of error. Tests are not multithreaded. Failure may be HW/OS version specific?

Printed result in failing CI has odd pattern 0xCCCCCD40 (debug) or 0xCCCCCDC4 (rel) which may be a clue. Will keep at it.

Note we have 0x0CCCCCCCD used in the gc at places as an "invalid gc value" when the shadow heap is enabled. However, enabling the shadow heap appears to require heapverify=2 and we're running with heapverify=1.

heapverify=1 also fills free memory within a heap to 0xCC.

category:correctness
theme:correctness
skill-level:intermediate
cost:small

[AndyAyersMS]

Linking back to master issue #9964.

[AndyAyersMS]

We don't have a lot of history here to go on but the tests passed at 9 and have failed since, though many of the follow on runs were for PRs.

So it might be something introduced after d104270 is contributing to this. But hard to be confident of this, given the rather sparse history.

@jashook @BruceForstall do we have rolling runs of this test leg vs master? If so perhaps we can see if this really looks like a recent regression or if these tests were failing sporadically all along.

[BruceForstall]

This should be the rolling run: https://ci.dot.net/job/dotnet_coreclr/job/master/job/jitstress/job/x86_checked_windows_nt_gcstress0xc_zapdisable_heapverify1/

Looks like the March 25 run passed.

[AndyAyersMS]

FWIW running these with heapverify=3 (which enables shadow heap checking for missing write barriers) fails immediately. Don't know yet if this heapverify feature is robust since we don't seem to enable it very often. I will debug this failure and see where it leads.

[AndyAyersMS]

Suspect the heapverify=3 failure is likely some bit of broken infrastructure around the shadow heap. So won't pursue that further.

Got a repro machine from CI and can't repro the failures above on that machine either. Nor on some of my other test machines.

[AndyAyersMS]

Still no local repro. Guess I will see if I can get back on a CI machine.

At any rate this is unlikely to be a jit issue as these tests are very simple. Think is is related to heapverify somehow.

[AndyAyersMS]

@RussKeldorph suggest we move this out of 2.1 as there's nothing we can do until we have a repro.

[AndyAyersMS]

This hasn't failed in the past 4 CI runs (all we have archived) so am going to close as no repro.... which should guarantee it fails again fairly soon.