Repository navigation
Description
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1588672
Failure
Browser-wasm CoreCLR outer-loop failed in JIT/Regression/JitBlue/GitHub_19361, Repro.Program.TestEntryPoint(), in the Regressions / Regression_NoOptimize_r_1 coverage:
Starting stress loop
WASM calli missing for key: MS56Tp
ASSERT FAILED
Expression: !"GetCookieForManagedMethod: unknown thunk signature"
Location: src/coreclr/vm/wasm/helpers.cpp:1488
Function: GetCookieForManagedMethod
Observed in builds 1588256, 1588672, and 1589561.
Correct routing and signature
The test uses ordinary managed LINQ and Parallel.For; it does not use P/Invoke, UnmanagedCallersOnly, explicit function pointers, or reverse P/Invoke.
MS56Tp is a managed interpreter-to-R2R thunk key:
M: managed interpreter-to-R2R transitionS56: 56-byte value-type return through a return bufferT: instance methodp: portable-entrypoint argument
The shape comes from the large ValueTuple<DateTime, CompositeSource, decimal> returned by a generic enumerator Current path. This is managed-call thunk lookup for a generic/value-type instantiation.
Resolution
This case was fixed by #133516. Structural sharing can find a Wasm R2R unboxing stub for a generic instantiation Crossgen2 never compiled, but that does not guarantee that the exact managed transition adapter (such as MS56Tp) exists. #133516 now retains exact per-target M and I transition dependencies for compiled targets and refuses to publish the structural native unboxing path when the exact incoming cookie is unavailable, falling back to the existing interpreted IL stub.
On current main, the exact Regression_NoOptimize_r_1 test reaches Starting stress loop, completes normally, and exits 100. A Checked debug diagnostic may still print WASM calli missing for key: MS56Tp while probing the structural unboxing optimization; that miss is now expected and causes the safe interpreted fallback rather than reaching GetCookieForManagedMethod with an unusable native target.
Build Analysis match
{
"ErrorMessage": [
"Expression: !\"GetCookieForManagedMethod: unknown thunk signature\"",
"src/coreclr/vm/wasm/helpers.cpp:1488"
],
"ErrorPattern": "",
"BuildRetry": false,
"ExcludeConsoleLog": false
}Note
This issue description was updated with GitHub Copilot assistance.
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1588672
Error message validated: [Expression: !"GetCookieForManagedMethod: unknown thunk signature" src/coreclr/vm/wasm/helpers.cpp:1488]
Result validation: ❌ Known issue did not match with the provided build.
Validation performed at: 9/10/2026 3:23:44 AM UTC
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsNo status
Activity
dotnet-policy-service commentedon Sep 10, 2026
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.
lewing commentedon Sep 10, 2026
Confirmed this is the
MS56Tpgeneric unboxing-transition case already fixed by #133516, not a reverse-P/Invoke failure.From clean current
main(3d884649ef9), I built browser-wasm CoreCLR with Checked runtime configuration and ran the exactglobal::Repro.Program.TestEntryPoint()inRegression_NoOptimize_r_1under Node. The test printedStarting stress loop, completed all five iterations, printedResult: Completed Normally, and the wrapper exited 100. The remaining debug-onlyWASM calli missing for key: MS56Tpis emitted by the deliberateGetUnboxingStubavailability probe added in #133516; the probe now rejects the unsafe structural native path and uses the interpreted IL-stub fallback.No additional product patch or PR is needed on current
main.Note
This comment was generated with GitHub Copilot assistance.
dotnet-policy-service commentedon Sep 10, 2026
Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.
[wasm] Fix duplicate R2R stack trace frames (#133610)