Disable certain stackoverflow tests

[kunalspathak]

#110173 is failing for more than 6 months now in multiple pipelines. Disable some tests to make CI green. We will continue to investigate #110173 and will re-enable them once fix is in.

cc: @janvorli

[Copilot]

Pull Request Overview

This PR temporarily disables additional StackOverflow tests on specific architectures and platforms to stabilize CI while issue #110173 is investigated.

• Expanded the skip conditions in TestStackOverflowLargeFrameSecondaryThread to include X64 and Arm on Unix/macOS.
• Extended the skip logic in TestStackOverflow3 to cover Unix ARM64.
• Added comments referencing the disabling reason and related issue.

Comments suppressed due to low confidence (1)

src/tests/baseservices/exceptions/stackoverflow/stackoverflowtester.cs:197

• [nitpick] Clarify this comment to explicitly state that both Unix X64 and Unix Arm are affected, e.g., 'Disabled on Unix X64 and Unix Arm due to…', to avoid ambiguity.

// Disabled on Unix X64/Arm due to https://github.com/dotnet/runtime/issues/110173 which needs investigation.

[Copilot]

[nitpick] Consider extracting the complex architecture and platform check into a well‐named helper method or boolean variable to improve readability and maintainability.

Suggested change

	if (((RuntimeInformation.ProcessArchitecture == Architecture.Arm64) || (RuntimeInformation.ProcessArchitecture == Architecture.X64) || (RuntimeInformation.ProcessArchitecture == Architecture.RiscV64) ||
	(RuntimeInformation.ProcessArchitecture == Architecture.LoongArch64) || (RuntimeInformation.ProcessArchitecture == Architecture.Arm)) &&
	((Environment.OSVersion.Platform == PlatformID.Unix) || (Environment.OSVersion.Platform == PlatformID.MacOSX)))
	if (IsUnixPlatformWithSpecificArchitecture())

[Copilot]

[nitpick] The condition in TestStackOverflow3 is quite dense; consider moving this logic into a named variable or helper for clarity and easier future updates.

Suggested change

	if ((RuntimeInformation.ProcessArchitecture == Architecture.Arm) || ((RuntimeInformation.ProcessArchitecture == Architecture.Arm64) && (Environment.OSVersion.Platform == PlatformID.Unix)))
	{
	// Disabled on ARM due to https://github.com/dotnet/runtime/issues/107184
	// Disabled on Unix ARM64 due to https://github.com/dotnet/runtime/issues/110173 which needs investigation.
	return;
	}
	if (ShouldDisableTest())
	{
	return;
	}
	private static bool ShouldDisableTest()
	{
	// Disabled on ARM due to https://github.com/dotnet/runtime/issues/107184
	// Disabled on Unix ARM64 due to https://github.com/dotnet/runtime/issues/110173 which needs investigation.
	return (RuntimeInformation.ProcessArchitecture == Architecture.Arm) ||
	((RuntimeInformation.ProcessArchitecture == Architecture.Arm64) && (Environment.OSVersion.Platform == PlatformID.Unix));
	}

[janvorli]

I agree it is a pain to have a test failing few times a week. But it seems that if we disable the test, there is no chance to figure out what's wrong, as I was unable to reproduce this problem locally, trying by running the test in a loop for weeks. Or even in CI by re-running relevant CI legs over and over in a targeted PR. The frequency of the CI test runs is the only thing that makes the problem fire from time to time. It seems there is some extremely rare combination of an async event and the stack overflow that triggers the behavior.

But maybe disabling it now and re-enabling it temporarily in the CI every time I figure out some extra logging / checks to try to figure out more details would work.

[kunalspathak]

But maybe disabling it now and re-enabling it temporarily in the CI every time I figure out some extra logging / checks to try to figure out more details would work.

I agree, that way the CI is clean and you can trigger CI from your branch with extra logging.

[janvorli]

Triggering it from my branch would not help, as it is unlikely it would ever repro that way. I was rather thinking to enable it globally for a while when I have some more ideas on added logging.

[kunalspathak]

/ba-g failure seems to be #116520

[AndyAyersMS]

Can we set up a special CI leg that runs this test over and over, and schedule that to run every day?