[ci-scan] Skip GC-assertion-crashing tests under interpreter (refs #127855)

[github-actions]

Linked KBE: #127855

Reasoning

Tests in System.Net.Requests.Tests, System.Net.WebSockets.Client.Tests, System.Text.RegularExpressions.Tests (library interpreter pipeline, def 330), and MarshalSeqStruct/ReversePInvoke (CoreCLR interpreter pipeline, def 316) crash the test process with a GC consistency assertion at gc.cpp:7379 is_in_heap_range (exit 133, SIGTRAP). The crash is a runtime-level GC issue triggered under interpreter mode; it kills the entire test runner process before xunit can report individual results. Suppressing all tests in these assemblies/classes under interpreter mode is the correct test-side fix — no product code change is needed.

The library tests use assembly-level [ActiveIssue] with PlatformDetection.IsInterpreter so xunit skips the whole assembly when running under either Mono or CoreCLR interpreter. The CoreCLR test uses [SkipOnCoreClr(..., RuntimeTestModes.InterpreterActive)] at class level, the standard pattern for that test suite.

Impact on platforms

• runtime-libraries-interpreter (def 330) · linux-x64 Release · System.Net.WebSockets.Client.Tests · exit 133 (SIGTRAP) — builds 1410559, 1408344, 1407439, 1406424, 1405212
• runtime-libraries-interpreter (def 330) · osx-arm64 Release · System.Net.Requests.Tests · exit 133 — all 5 scanned builds
• runtime-libraries-interpreter (def 330) · osx-arm64 Release · System.Text.RegularExpressions.Tests · exit 133 — all 5 scanned builds
• runtime-interpreter (def 316) · osx-arm64 Checked / osx-x64 Checked · Interop/StructMarshalling/ReversePInvoke/MarshalSeqStruct/ReversePInvoke/ReversePInvokeTest · exit 133 — builds 1410560, 1407440

Errors log

ASSERT FAILED
    Expression: ((g_gc_lowest_address <= o) && (o < g_gc_highest_address)) || (o == nullptr) || (ro_segment_lookup (o) != nullptr)
    Location:   src/coreclr/gc/gc.cpp:7379
    Function:   is_in_heap_range
./RunTests.sh: line 175: 87624 Trace/BPT trap: 5  "$RUNTIME_PATH/dotnet" exec ... System.Net.Requests.Tests.dll

First build it occurred

First observed in scanned window: build 1405212 (May 1, 2026). All 5 scanned builds of pipeline 330 are affected. This is computed within the scanned window and may not be the true origin.

Linked issue

KBE: #127855

Note

🤖 This PR was generated by the CI Outer-Loop Failure Scanner.

Note

🔒 Integrity filter blocked 1 item

The following item were blocked because they don't meet the GitHub integrity level.

• #110173 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 16.2M · ◷

[dotnet-policy-service]

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

[BrzVlad]

This has nothing to do with gc crashes. It should be fixed by #127758

[BrzVlad]

@kotlarmilos I would rather not disable these tests suites for now. Also there might be multiple suites that get impacted by this in an intermittent fashion. I want to go into a deeper investigation in the near future, depending how reliably I can reproduce. Can we just have a known test failure for this ?

[kotlarmilos]

This PR was opened against #127855. The assumption was that KBEs should be used to unblock other PRs on recent failures until the fix lands. The problem here is that it didn't find your PR as related and it wasn't linked, so it tried to fix it with this PR instead.

I will improve the workflow to look for linked PRs and issues. One thing we could do is add a label if this starts to happen frequently and skip KBEs with the label and avoid the fix attempt. If you want to keep the issue tracking some work and don't expect a fast fix, I suggest disabling the tests, since this is the only approach to achieve green CI.

[kotlarmilos]

Updated your PR to link the issue. I will close this PR and let's monitor if it picks your PR as a valid fix in the next run.