Skip to content

Fix OOM crash (exit 137) in System.Runtime.Tests OuterLoop on Linux Debug/Checked CoreCLR #126013

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Copilot wants to merge 2 commits into from
Closed

Fix OOM crash (exit 137) in System.Runtime.Tests OuterLoop on Linux Debug/Checked CoreCLR #126013

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b4c265d
Initial plan
Copilot Mar 24, 2026
10aaed3
Fix OOM crash in System.Runtime.Tests on Linux Debug/Checked CoreCLR
Copilot Mar 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 20 additions & 22 deletions src/libraries/System.Runtime/tests/System.Runtime.Tests/System/GCTests.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1026,19 +1026,18 @@ private static void AllocateUninitializedArray()
arr[i - 1] = "17";
Assert.True(arr[0] == "5" && arr[i - 1] == "17");
}
}

// allocate max size byte array
{
if (IntPtr.Size == 8)
{
int i = 0x7FFFFFC7;
var arr = GC.AllocateUninitializedArray<byte>(i);
[ConditionalFact(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess), nameof(PlatformDetection.IsReleaseRuntime))]
Copy link
Copy Markdown
Member

@jkotas jkotas Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Debug/Checked CoreCLR, runtime overhead pushes this over the cgroup memory limit, causing SIGKILL (exit code 137).

The difference between checked and release runtime overhead is negligible relative to the GBs of memory that this test allocates. IsReleaseRuntime condition does not make sense to me.

Copy link
Copy Markdown
Member

@jkotas jkotas Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are seeing these failures on checked build only, it suggests that there is something very inefficient in checked runtime for arrays of this size. We should fix that instead of disabling the test.

Copy link
Copy Markdown
Member

@danmoseley danmoseley Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good

[OuterLoop]
Comment on lines +1031 to +1032
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The guard here (IsReleaseRuntime) skips this max-size allocation on all non-Release runtime builds across OSes/runtimes. The PR description says the issue is specific to Linux Debug/Checked CoreCLR, so this condition looks broader than intended; consider adding narrower conditions (e.g., IsLinux and/or IsCoreCLR) or updating the PR description to match the new behavior.

Copilot uses AI. Check for mistakes.
private static void AllocateUninitializedArray_MaxSize()
{
int i = 0x7FFFFFC7;
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0x7FFFFFC7 is a magic number. Consider using Array.MaxLength (or a named constant) to self-document that this is the maximum supported array length and avoid duplicating the value in multiple tests.

Suggested change
int i = 0x7FFFFFC7;
int i = Array.MaxLength;

Copilot uses AI. Check for mistakes.
var arr = GC.AllocateUninitializedArray<byte>(i);

arr[0] = 5;
arr[i - 1] = 17;
Assert.True(arr[0] == 5 && arr[i - 1] == 17);
}
}
arr[0] = 5;
arr[i - 1] = 17;
Assert.True(arr[0] == 5 && arr[i - 1] == 17);
}

[Fact]
Expand Down Expand Up @@ -1080,19 +1079,18 @@ private static void AllocateArray()
arr[i - 1] = "17";
Assert.True(arr[0] == "5" && arr[i - 1] == "17");
}
}

// allocate max size byte array
{
if (IntPtr.Size == 8)
{
int i = 0x7FFFFFC7;
var arr = GC.AllocateArray<byte>(i);
[ConditionalFact(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess), nameof(PlatformDetection.IsReleaseRuntime))]
[OuterLoop]
Comment on lines +1084 to +1085
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The guard here (IsReleaseRuntime) skips this max-size allocation on all non-Release runtime builds across OSes/runtimes. The PR description says the issue is specific to Linux Debug/Checked CoreCLR, so this condition looks broader than intended; consider adding narrower conditions (e.g., IsLinux and/or IsCoreCLR) or updating the PR description to match the new behavior.

Copilot uses AI. Check for mistakes.
private static void AllocateArray_MaxSize()
{
int i = 0x7FFFFFC7;
var arr = GC.AllocateArray<byte>(i);
Comment on lines +1088 to +1089
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0x7FFFFFC7 is a magic number. Consider using Array.MaxLength (or a named constant) to self-document that this is the maximum supported array length and avoid duplicating the value in multiple tests.

Copilot uses AI. Check for mistakes.

arr[0] = 5;
arr[i - 1] = 17;
Assert.True(arr[0] == 5 && arr[i - 1] == 17);
}
}
arr[0] = 5;
arr[i - 1] = 17;
Assert.True(arr[0] == 5 && arr[i - 1] == 17);
}

[Theory]
Expand Down
Loading