Revert "Enable test for MemoryBarrierProcessWide on arm64. Update comments." #35974
Conversation
| @@ -302,7 +302,7 @@ public void InterlockedOr_UInt64() | |||
| Assert.Equal(0x17755771u, value); | |||
| } | |||
|
|
|||
| [Fact] | |||
| [ConditionalFact(typeof(PlatformDetection), nameof(PlatformDetection.IsNotArm64Process))] // [ActiveIssue("https://github.com/dotnet/runtime/issues/11177")] | |||
There was a problem hiding this comment.
Instead of disabling it, can we check the OS version inside the test and skip the test if we are running on OS that is known to have bugs in this?
There was a problem hiding this comment.
Look for throw new SkipTestException to see the pattern to use.
There was a problem hiding this comment.
Environment.OSVersion returns the Linux kernel version.
There was a problem hiding this comment.
Yes we should consider that. My first reaction though is to just revert - to fix the CI nuisance.
There was a problem hiding this comment.
Also it looks like the reported failure was on net5.0-Windows_NT-Release-arm64-CoreCLR_release-Windows.10.Arm64.Open
|
I am thinking - maybe we should have this test enabled for a little bit longer. It is actually a rare failure. (It was confused with something else when reported as failing every job) We have seen this only twice so far. Both times today and on Windows, which is a concern, since that has been reliable in the past. Maybe keeping it on and getting more failures could help with figuring whether this is OS-specific or more likely to be some testcase issue? |
rerun CI
|
There were more Windows failures. That is unexpected. It was Linux which used to have issues in the past. See: #11177 (comment) |
ghost
locked as resolved and limited conversation to collaborators
Reverts #35817
Failures in CI