Assert failure: Popping a frame out of order in browser-wasm ReadyToRun runtime tests
- Dominant language
- C#
- Stars
- 18.3k
- Forks
- 5.6k
- PR merge metrics
- PR metrics pending
Description
## Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1582146
Build error leg or test failing: `coreclr Pri0 Runtime Tests Run R2R_CG2 browser wasm checked` — `Regression_1` work item
Pull request: https://github.com/dotnet/runtime/pull/133210
The `Regression_1` work item in the browser-wasm ReadyToRun runtime-test leg asserts in `Frame::Pop` with frame-chain corruption. Helix job `f484f658-1090-4625-adf3-8f35293caf50`.
This is a **different shape** from #133219 (`Object::Validate`, GC-mode) and from the now-fixed #133220 (`Thread::ObjectRefFlush`). It is a frame-chain ordering assert, not a GC-mode assert, so it needs its own match block — Build Analysis matches on error text.
Helix categorises this as `InfrastructureError`. It is not — it is a real product assert in a checked runtime.
## Error Details
```
at EHTest.f1(Int64 arg0, Int64 arg1, Int64 arg2, Int32 arg3, Int64 arg4)
01:14:07.505 Failed test: JIT/Regression/CLR-x86-JIT/V2.0-Beta2/b125091/b125091/b125091.dll
ASSERT FAILED
Expression: pThread->GetFrame() == this && "Popping a frame out of order ?"
Location: /__w/1/s/src/coreclr/vm/frames.cpp:609
Function: Pop
Process: 42
Frame (PrestubMethodFrame): 0x4fef1c
Skipping 0x4fef1c
```
The failing test is `JIT/Regression/CLR-x86-JIT/V2.0-Beta2/b125091`, an exception-handling test. The assert fires immediately after a `System.AppDomainUnloadedException` surfaces from `EHTest.f1`.
## Context
Every remaining failure in this leg is an exception-handling test reaching an R2R delay-load pinvoke — `b125091` here, `NonVoidThrowHelper` in `JIT.opt` (#133219), `throwinfinally_50` in `Methodical_d1`, `CctorThrowInlinedStatic` in `Loader`. That is a better characterisation of the residue than the generic-dictionary-lookup theory in #132022, which #132420 already addressed.
### Lead, not a fix
`PopExplicitFrames` (`src/coreclr/vm/exceptionhandling.cpp:481-510`) decides whether to pop or merely `Reset()` an active `InlinedCallFrame` when an exception unwinds through an inline pinvoke. It tests `ExecutionManager::IsReadyToRunCode(m_pCallerReturnAddress)`, but wasm has no return address — `JIT_PInvokeBeginImpl` (`src/coreclr/vm/wasm/helpers.cpp:708`) stores the sentinel `INLINED_PINVOKE_FROM_R2R` (`== 1`, `frames.h:792`). `IsReadyToRunCode((PCODE)1)` finds no RangeSection and returns false, so the frame is `Reset()` but left linked on the thread frame chain. `stackwalk.cpp:2335` already special-cases this exact sentinel under `#ifdef TARGET_WASM`; `PopExplicitFrames` has no equivalent. `USE_PER_FRAME_PINVOKE_INIT` is `TARGET_64BIT`-only, so wasm32 takes that branch.
That is a plausible cause of *this* assert specifically. It has **not** been validated against this test — a prototype was built and tested against `JIT.opt`/#133219, where it changed nothing, and was reverted rather than shipped unverified. Recording it so the next person does not have to re-derive it.
## Error Message
```json
{
"ErrorMessage": [
"Expression: pThread->GetFrame() == this && \"Popping a frame out of order ?\"",
"Location: /__w/1/s/src/coreclr/vm/frames.cpp:609",
"Function: Pop",
"Process: 42"
],
"ErrorPattern": "",
"BuildRetry": false,
"ExcludeConsoleLog": false
}
```
### Why the match block is scoped this way
Array form: each element matches one line, in order, with arbitrary lines allowed between them.
`"Popping a frame out of order ?"` on its own is platform-neutral and would match this assert anywhere, on any architecture. The four elements together scope it: exact assert text, exact source location, asserting function, and `Process: 42` — emscripten's fixed PID, which native platforms do not report. That last element keeps the match on browser-wasm.
All four elements were verified verbatim against the `Regression_1` console log for Helix job `f484f658-1090-4625-adf3-8f35293caf50`.
Match-block verification
Every element was checked verbatim against the failing Helix console log for the job cited above.
The element set (`Expression:` / `Location:` / `Function:` / `Process:`) mirrors the block in #131925, which matched this same assert 277 times in a month — evidence that these lines are present in the artifact Build Analysis matches against. #131925 stopped matching because its block additionally pins `object.cpp:514` (this build reports `:506`) and text specific to `Loader/ContextualReflection`, whose test has since been disabled on browser-wasm.
Outstanding: I have not yet observed a Build Analysis run attribute an occurrence to this issue, so the match is reasoned rather than demonstrated. If it does not pick up, the likely cause is that these merged-runner work items abort without publishing a test result for Build Analysis to attach to, in which case the fallback is a test-disable change rather than a KBE.
> [!NOTE]
> This issue was authored with GitHub Copilot.
### Known issue validation
**Build: :mag_right:** https://dev.azure.com/dnceng-public/public/_build/results?buildId=1582146
**Error message validated:** `[Expression: pThread->GetFrame() == this && "Popping a frame out of order ?" Location: /__w/1/s/src/coreclr/vm/frames.cpp:609 Function: Pop Process: 42`]
**Result validation:** :x: Known issue did not match with the provided build.
**Validation performed at:** 9/4/2026 3:40:40 AM UTC
### Report
|Build|Repository|Test|Pull Request|
|---|---|---|---|
|[1593290](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1593290)|dotnet/runtime|[Regression_1.WorkItemExecution](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1593290&view=ms.vss-test-web.build-test-results-tab&runId=43980730&resultId=101995)|dotnet/runtime#133146|
|[1590032](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1590032)|dotnet/runtime|[Regression_1.WorkItemExecution](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1590032&view=ms.vss-test-web.build-test-results-tab&runId=43889526&resultId=101517)|dotnet/runtime#133146|
#### Summary
|24-Hour Hit Count|7-Day Hit Count|1-Month Count|
|---|---|---|
|0|2|2|
Contributor guide
Assessment
This issue has not been assessed yet.