Assert failure: thread->PreemptiveGCDisabled() in ObjectRefFlush in browser-wasm ReadyToRun runtime tests

[lewing]

Build Information

Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1581582
Build error leg or test failing: coreclr Pri0 Runtime Tests Run R2R_CG2 browser wasm checked — reflection work item
Pull request: #133136

The reflection work item in the browser-wasm ReadyToRun runtime-test leg asserts in Thread::ObjectRefFlush. It fails deterministically — the same work item fails in both 1580911 (Helix job 20b86593-abb9-407d-9cd2-35a9f3ca8784) and 1581582 (Helix job 091c9316-24e7-4e7a-964c-940d0e133fdc).

Helix categorises this as InfrastructureError. It is not — it is a real product assert in a checked runtime.

Relationship to other issues

This is the same underlying defect as #133219, #131925, and #132022 — a thread left in preemptive GC mode on the browser-wasm ReadyToRun path — caught at a different debug checkpoint.

It is filed separately from #133219 only because Build Analysis matches on error text, and this assert's text differs. Object::Validate catches the bad mode on the next OBJECTREF access (#133219, 20 work items); Thread::ObjectRefFlush catches it on entry to the fixup worker (this issue, 1 work item). Consolidate if a maintainer prefers.

Error Details

19:53:05.741 Running test: reflection/DisallowAbstractConstructors/DisallowAbstractConstructors/DisallowAbstractConstructors.dll
ASSERT FAILED
	Expression: thread->PreemptiveGCDisabled()
	Location:   /__w/1/s/src/coreclr/vm/threads.cpp:4624
	Function:   ObjectRefFlush
	Process:    42
Frame (PrestubMethodFrame): 0x4febdc
    Skipping 0x4febdc
Frame (PrestubMethodFrame): 0x4fef1c
    Skipping 0x4fef1c
Frame (PrestubMethodFrame): 0x4ff28c

Error Message

{
  "ErrorMessage": [
    "Expression: thread->PreemptiveGCDisabled()",
    "Location:   /__w/1/s/src/coreclr/vm/threads.cpp:4624",
    "Function:   ObjectRefFlush",
    "Process:    42"
  ],
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Why the match block is scoped this way

This uses the array form: each element matches one line, in order, with arbitrary lines allowed between them.

thread->PreemptiveGCDisabled() on its own is not a usable signature — it appears at 26 assert sites across the VM and is platform-neutral, so matching it alone would mark unrelated failures on any platform as known.

The four elements together scope the match: the exact assert text, the exact source location, the asserting function, and Process: 42 — emscripten's fixed PID, which native platforms do not report. That last element is what keeps the match on browser-wasm.

All four elements were verified verbatim against the reflection console log for Helix job 091c9316-24e7-4e7a-964c-940d0e133fdc. The frame chain is deliberately excluded because the innermost frame varies by work item across this failure family.

Note

This issue was authored with GitHub Copilot.

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1581582
Error message validated: [Expression: thread->PreemptiveGCDisabled() Location: /__w/1/s/src/coreclr/vm/threads.cpp:4624 Function: ObjectRefFlush Process: 42]
Result validation: ❌ Known issue did not match with the provided build.
Validation performed at: 9/4/2026 3:06:22 AM UTC

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[lewing]

Fixed by #132420 (d1a8a7d2c80, "Route QCall exceptions through marshalling", merged 2026-09-03 20:29 UTC).

Both builds referenced above predate that commit. The first post-fix CI run of this leg is build 1582146 — merge commit fcfdc22e638, confirmed to contain d1a8a7d2c80 — Helix job f484f658-1090-4625-adf3-8f35293caf50. The reflection work item passes there, and this ObjectRefFlush signature does not occur anywhere in that job.

Closing so it does not mark a future regression as known.

Note that the leg as a whole is still red: 17 of 82 work items fail post-fix, down from 21. The Object::Validate signature in #133219 still reproduces via JIT.opt, so that issue stays open, and some of the residue is a different failure shape that still needs triage.

Note

This comment was authored with GitHub Copilot.