Repository navigation
[ci-scan] Test failure: JIT/Regression/CLR-x86-JIT/V1-M12-Beta2/b65423 crashes on browser-wasm with strerror called after runt
[Content truncated due to length] #131937
Description
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1541935
Build error leg or test failing: coreclr Pri1 Runtime Tests Run browser wasm checked - JIT/Regression/CLR-x86-JIT/V1-M12-Beta2/b65423/b65423/b65423.cmd
Error Details
The b65423 JIT regression test fails on the runtime-coreclr outerloop browser-wasm checked leg. After catching the expected TypeLoadException (exit 100), the wasm runtime aborts during shutdown because strerror is invoked after the runtime has exited. The test then reports Expected 100 / Actual 1.
Caught TypeLoadException exception: 100
Aborted(Assertion failed: native function `strerror` called after runtime exit (use NO_EXIT_RUNTIME to keep it alive after main() exits))
(wasm/redacted)
RuntimeError: unreachable
at abort (corerun.js)
at assert (corerun.js)
at strError (corerun.js)
at new ErrnoError (corerun.js)
at Object.getStreamChecked (corerun.js)
at Object.getStreamFromFD (corerun.js)
at _fd_write (corerun.js)
Expected: 100
Actual: 1
END EXECUTION - FAILED
02:10:36.782 Failed test: JIT/Regression/CLR-x86-JIT/V1-M12-Beta2/b65423/b65423/b65423.cmd
Observed in build 1541935 (2026-08-06) and reproduced in follow-up build 1542249 on the same leg.
Error Message
{
"ErrorMessage": [
"Aborted(Assertion failed: native function `strerror` called after runtime exit (use NO_EXIT_RUNTIME to keep it alive after main() exits))",
"Failed test: JIT/Regression/CLR-x86-JIT/V1-M12-Beta2/b65423/b65423/b65423.cmd"
],
"ErrorPattern": "",
"BuildRetry": false,
"ExcludeConsoleLog": false
}Filed by ci-failure-scan (detection only). ci-failure-fix walks open [ci-scan] KBEs and either opens a small fix PR or comments here to loop in owners — it never disables the test.
Note
This issue was generated by an AI agent (ci-failure-scan Copilot workflow).
Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
awmgmcpg
To allow these domains, add them to the
network.allowedlist in your workflow frontmatter:
network:
allowed:
- defaults
- "awmgmcpg"See Network Configuration for more information.
Generated by CI Outer-Loop Failure Scanner · 554.9 AIC · ⌖ 12.2 AIC · ⊞ 18.3K · ◷
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 3 | 14 | 14 |
Activity
dotnet-policy-service commentedon Aug 6, 2026
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Aug 6, 2026
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.
JulieLeeMSFT commentedon Aug 6, 2026
@pavelsavara, PTAL.
cc @dotnet/wasm-contrib.
github-actions commentedon Aug 8, 2026
Workflow artifact: ci-fix
Artifact kind: handoff
Linked KBE: #131937
Note
AI/Copilot-generated triage note.
This Known Build Error has no producible automated code change (reason: non-code/infra failure in the wasm runtime shutdown path — not something I can correct with a small, safe source diff, and the only test-side "fix" would be to disable the test, which this workflow must never do), so I could not open even a best-effort PR. Looping in owners so it can be fixed forward rather than muted.
Root cause (best analysis)
On the
runtime-coreclr outerloopbrowser-wasm checked leg,JIT/Regression/CLR-x86-JIT/V1-M12-Beta2/b65423catches its expectedTypeLoadException(which is the intendedExpected: 100result), but the wasm runtime then aborts during shutdown:The test logic itself passes; the failure is that an Emscripten
strerror/_fd_writecall (a flush of stdout/stderr) runs aftermain()has returned and the runtime has exited, tripping the "called after runtime exit" assertion and turning exit code 100 into 1. This is a wasm host/shutdown ordering issue (a latefd_writeon a torn-down runtime), not a JIT codegen defect and not a defect in the test body — so no source-level test change is appropriate, and disabling the test is out of scope for this workflow.Evidence
Suggested reviewers / area contacts
arch-wasm):@lewing,@pavelsavaraA fix would likely involve keeping the wasm runtime alive long enough to flush stdio during shutdown (e.g. the
NO_EXIT_RUNTIME/ late-fd_writehandling in the CoreCLR wasm hostcorerun.jsglue), so the post-exitstrerrorassertion no longer fires after a passing test.Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
awmgmcpgSee Network Configuration for more information.
[browser][coreCLR] corerun: hard-exit Node on explicit process exit (#…
[browser][coreCLR] corerun: hard-exit Node on explicit process exit (d…