[browser][coreCLR] corerun: hard-exit Node on explicit process exit (#131937)

[pavelsavara]

Problem

JIT/Regression/CLR-x86-JIT/V1-M12-Beta2/b65423 fails on the browser-wasm CoreCLR checked leg (#131937). The test catches its expected TypeLoadException (the intended Expected: 100), but the wasm runtime then aborts during shutdown:

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))
... at _fd_write (corerun.js)
Expected: 100
Actual: 1

Root cause

The test ends with Environment.Exit(100). On browser-wasm that goes Environment_Exit → ForceEEShutdown → EEPolicy::HandleExitProcess → SafeExitProcess → ExitProcess → PROCEndProcess → Emscripten exit() (the host links -sEXIT_RUNTIME=1).

Emscripten's exitJS runs exitRuntime() — tearing down the Emscripten FS/TTY and setting runtimeExited=true — then _proc_exit throws the ExitStatus JS exception. That exception unwinds up through the still-live CLR interpreter frames (wasm EH). During the unwind, Frame::Pop(Thread*) calls Thread::GetFrame(), whose checked-only _ASSERTE (curSP <= m_pFrame && m_pFrame < m_CacheStackBase) fails because we are exiting mid-interpretation. The assert's fprintf(stderr, ...) then hits musl stdio → fd_write → the FS streams are already gone → getStreamChecked throws ErrnoError, and building its message calls strerror, tripping Emscripten's assert(!runtimeExited) → abort(). The abort turns the intended exit code 100 into 1.

This only reproduces on the checked leg because the triggering GetFrame() assert exists only under _DEBUG_IMPL.

Fix

In the corerun wasm glue, under Node, intercept _proc_exit and end the process immediately with process.exit(code) when the runtime is not kept alive — avoiding the ExitStatus throw and the unwind through live CLR frames. stdio was already flushed by exitRuntime() before _proc_exit is reached. The browser/keepalive/onExit path is untouched (Node-gated), and when the runtime is kept alive for async work it falls through to the original behavior.

_proc_exit is the correct interception point: wasmImports.exit binds the original exitJS by value (so reassigning exitJS would miss the wasm-initiated Environment.Exit), but exitJS's body calls _proc_exit by variable reference at call time.

Validation

Ran the assembled b65423.dll under corerun.js in Node, exactly as CI does:

corerun.js	Node exit
before fix	1 (strerror abort — matches the issue)
after fix	100 (expected)

Regression checks also pass: normal return 7 from Main → exit 7; Environment.Exit(0) → exit 0.

Fixes#131937

Note

This PR description was generated with the assistance of GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Fixes a browser-wasm CoreCLR checked-leg test failure where Environment.Exit(...) triggers an Emscripten ExitStatus throw that unwinds through live interpreter frames and aborts with the wrong exit code under Node.

Changes:

• Under Node, intercept _proc_exit to hard-exit via process.exit(code) when the runtime is not being kept alive.
• Preserve existing behavior for non-Node environments and for keepalive/async scenarios by delegating to the original _proc_exit.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/coreclr/hosts/corerun/wasm/libCorerun.js:43

• Local variable original_proc_exit uses snake_case, which is inconsistent with the surrounding camelCase naming in this file. Consider renaming to originalProcExit while keeping the Emscripten-provided _proc_exit identifier as-is.

 const original_proc_exit = _proc_exit;
_proc_exit = (code) => {
if (!keepRuntimeAlive()) {
process.exit(code);
}
return original_proc_exit(code);
};