[browser] Fix Debug-only startup failures: stack-first assert, incoming Module API, preRun function form by pavelsavara · Pull Request #134527 · dotnet/runtime

pavelsavara · 2026-09-23T14:55:02Z

Three unrelated-looking failures that all only reproduce in Debug browser builds, plus one follow-on cleanup.

1. Mono MT asserts on the stack bounds at startup

* Assertion at src/mono/mono/utils/mono-threads-wasm.c:201, condition `*staddr != NULL' not met
  at mono_threads_platform_get_stack_bounds
  at mono_thread_info_get_stack_bounds
  at register_thread
  at mono_wasm_register_ui_thread

At -O0 emscripten links with --stack-first, which puts the stack at the start of linear memory, so __stack_low == 0. pthread_getattr_np reports stack = emscripten_stack_get_base() and stack_size = base - end, and pthread_attr_getstack returns stack - stack_size, i.e. emscripten_stack_get_end() — legitimately NULL under this layout. Emscripten also comments out musl's if (!a->_a_stackaddr) return EINVAL, so the call succeeds and the assert is what fires.

Mono already accounts for this everywhere else: register_thread has an explicit #ifndef TARGET_WASM around g_assert (staddr) with the comment "for wasm, the stack can be placed at the start of the linear memory", and the non-pthreads branch of mono_threads_platform_get_stack_bounds has no NULL assert at all — which is why Debug single-threaded works. Only the __EMSCRIPTEN_PTHREADS__ branch was missed.

The *stsize != (size_t)-1 assert stays, so a genuinely uninitialized main pthread (stack = 0, stack_size = 0) is still caught by g_assert (stsize) in register_thread.

2. `Module.wasmMemory was supplied but wasmMemory not included in INCOMING_MODULE_JS_API`

With assertions on, emscripten aborts when a Module property is supplied that isn't declared. Mono's MT worker sets Module.wasmMemory when it receives the mono config, and wasmMemory is not in emscripten's default list — so Debug + MT + Mono aborts during startup.

Both flavors now declare INCOMING_MODULE_JS_API explicitly: emscripten's full default set, plus wasmMemory for Mono when threads are enabled. Nothing that works today changes, and an undeclared property still fails loudly at link instead of silently.

An earlier revision of this PR listed only the properties the loaders themselves set, which rejected 16 properties emscripten accepts by default. That turned out to be reachable from user code — Blazor's prepareRuntimeConfig does ...(window['Module'] || {}) into the module config, so an app author can put any emscripten property on window.Module and it would have aborted a debug build. Hence the full default set.

Adding wasmMemory is behaviourally neutral: initMemory() returns early on a pthread before reaching the Module['wasmMemory'] branch, and the main thread never sets it.

corerun is deliberately left on the default list — its JS injects no Module properties, and corerun.html assigns monitorRunDependencies.

3. `TypeError: (Module.preRun || []) is not iterable`

Emscripten lets preInit/preRun/postRun be an array or a single callback, and normalizes them itself. The browser host prepends its own hooks by spreading the user value, so a single function throws. Mono already normalizes this in configureEmscriptenStartup.

WasmBasicTestApp passes preRun as a function, which is how Wasm.Build.Tests hit it after moving to the standard workload. EmscriptenModuleInternal declared these as arrays only, which is what allowed the assumption — widened to match Mono's EmscriptenModule. postRun needs no normalization because the host never prepends to it.

Verification

Mono -subset mono -c Debug /p:WasmEnableThreads=true builds; in the regenerated dotnet.native.js, checkIncomingModuleAPI rejects exactly what stock emscripten rejects minus wasmMemory.
CoreCLR -subset clr+host -c Debug builds; the browserhost dotnet.native.js rejects exactly what stock emscripten rejects.
npm run rollup:debug and npm run lint are clean under src/native.

Not runtime-tested: no Wasm.Build.Tests or xharness run yet. That gap is what let the BrowserWasmApp.CoreCLR.targets ordering bug above go unnoticed until a second review pass, since the workload relink targets are only exercised by those tests — worth running before this leaves draft.

Resolves #132555

Note

This pull request description was generated with GitHub Copilot.

Emscripten lets preInit/preRun/postRun be either an array of callbacks or a single callback, and normalizes them itself. The browser host prepends its own hooks by spreading the user value, which throws "(Module.preRun || []) is not iterable" when a single function was supplied. Mono already normalizes this in configureEmscriptenStartup. WasmBasicTestApp passes preRun as a function, which is how Wasm.Build.Tests hit this once it moved to the standard workload. EmscriptenModuleInternal declared these as arrays only, which is what allowed the assumption in the first place, so widen them to match Mono's EmscriptenModule. postRun needs no normalization here because the host never prepends to it. Also apply npm run format, which reflows an arrow body in http.ts that was failing the brace-style lint rule. Fixes dotnet#132555

azure-pipelines · 2026-09-23T14:55:52Z

Azure Pipelines: Successfully started running 4 pipeline(s). 12 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 · 2026-09-23T14:56:22Z

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

The earlier list only named the properties the loaders themselves set, which rejected 16 properties emscripten accepts by default. That is reachable from user code: Blazor's prepareRuntimeConfig spreads window['Module'] into the module config, so an app author can put any emscripten property there and it would abort a debug build. Declare the default set on both flavors instead, plus wasmMemory for Mono with threads, which is the one property we set that is not a default. The setting stays explicit so an undeclared property still fails at link rather than silently, but nothing that works today changes. Also fix the ordering in BrowserWasmApp.CoreCLR.targets: the PropertyGroup computing _EmccIncomingModuleJSAPI ran before the ItemGroup defining the items, and MSBuild evaluates a target's children in document order, so the list expanded to empty and rejected every Module property on the workload relink path.

Emscripten serializes dotnetInitializeModule independently of its bundle closure. Keep the callback normalization helper nested so Rollup's minified name remains available in dotnet.native.js. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot review overview

🟡 Changes recommended

A Debug CoreCLR workload/native-relink test is needed before approval.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

Add Debug CoreCLR native relink test covering browser startup · New

What changed in this PR

Fixes Debug-only WebAssembly browser startup failures across Mono, CoreCLR, and JavaScript interop.

Changes:

Handles stack-first WASM stack bounds.
Declares Emscripten incoming Module APIs.
Supports function-form startup callbacks.
Corrects CoreCLR MSBuild evaluation order.

File	Summary
`src/native/libs/System.Runtime.InteropServices.JavaScript.Native/interop/http.ts`	Formatting cleanup.
`src/native/libs/System.Native.Browser/native/index.ts`	Normalizes callback values.
`src/native/libs/Common/JavaScript/types/internal.ts`	Widens callback type definitions.
`src/native/corehost/browserhost/CMakeLists.txt`	Adds the explicit Module API allowlist.
`src/mono/mono/utils/mono-threads-wasm.c`	Allows a null stack base for stack-first builds.
`src/mono/browser/build/BrowserWasmApp.targets`	Adds Mono linker API configuration; duplicated allowlist remains a nit.
`src/mono/browser/build/BrowserWasmApp.CoreCLR.targets`	Adds CoreCLR relink API configuration; requires a Debug workload/native-relink test.
`src/mono/browser/browser.proj`	Adds Mono browser API configuration.

pavelsavara · 2026-09-25T16:28:14Z

+
    <PropertyGroup>
      <_EmccExportedRuntimeMethods>"[BROWSER_HOST,@(EmccExportedRuntimeMethod -> '%27%(Identity)%27', ',')]"</_EmccExportedRuntimeMethods>
+      <_EmccIncomingModuleJSAPI>"[@(EmccIncomingModuleJSAPI -> '%27%(Identity)%27', ',')]"</_EmccIncomingModuleJSAPI>


Structurally addressed: the items now come from the GenerateEmccExports dependency, so the ItemGroup-before-PropertyGroup ordering hazard this flags is gone. The CoreCLR in-tree browserhost link was rebuilt and its checkIncomingModuleAPI is unchanged (rejects wasmMemory/wasmBinary, accepts the 26 defaults). A full Wasm.Build.Tests/xharness Debug startup run is still pending, so I'm leaving this open until that runs.

_{Note: written with GitHub Copilot.}

akoeplinger · 2026-09-25T16:13:51Z

 		g_error ("%s: pthread_attr_destroy failed with \"%s\" (%d)", __func__, g_strerror (res), res);

-	g_assert (*staddr != NULL);
+	// emscripten links with --stack-first at -O0, which puts the stack at the start of the linear memory, so staddr can legitimately be NULL


we should probably backport this to 11.0 (we could argue it's a test-only change since it happens in Debug only) since it will get lost in main soon

Nobody in the world ever builds mono+MT+wasm+debug. And I'm not going to do it any time soon again.

The explicit emscripten default INCOMING_MODULE_JS_API list was hand-copied into four files. Collapse it to a single source per flavor, matching how EXPORTED_FUNCTIONS/RUNTIME_METHODS already flow. CoreCLR: define the list in GenerateEmccExports (eng/native.wasm.targets plus its fallback in BrowserWasmApp.CoreCLR.targets). The in-tree browserhost link now consumes a CMAKE_EMCC_INCOMING_MODULE_JS_API cmake arg instead of a hardcoded string, and _CoreCLRWriteLinkRsp reads the items from its GenerateEmccExports dependency. This also removes the earlier ItemGroup-before-PropertyGroup ordering hazard, since the items are populated by a dependency target. Mono: browser.proj remains the single source and now emits EmccDefaultIncomingModuleJSAPI into wasm-props.json (incl. wasmMemory for the threads pack variant). ReadWasmProps surfaces it and the app relink in BrowserWasmApp.targets reads it instead of re-listing. CoreCLR browserhost dotnet.native.js checkIncomingModuleAPI is unchanged (rejects wasmMemory/wasmBinary, accepts the 26 defaults). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot review overview

🟡 Changes recommended

Null stack-base range checks remain unsafe and must be guarded.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 · 1

Open (2)

Guard stack range checks when stack base is NULL · New
Add Debug CoreCLR native relink test covering browser startup

+	// emscripten links with --stack-first at -O0, which puts the stack at the start of the linear memory, so staddr can legitimately be NULL
 	g_assert (*stsize != (size_t)-1);


pavelsavara added 4 commits September 23, 2026 16:09

--stack-first

e03f7ed

INCOMING_MODULE_JS_API

01aa2d4

more

33c23b8

dotnet-policy-service Bot assigned pavelsavara Sep 23, 2026

github-actions Bot added the area-Build-mono label Sep 23, 2026

pavelsavara added arch-wasm WebAssembly architecture os-browser Browser variant of arch-wasm labels Sep 23, 2026

pavelsavara added this to the 12.0.0 milestone Sep 23, 2026

pavelsavara mentioned this pull request Sep 23, 2026

[browser] Add withDownloadResourceProgress to DotnetHostBuilder #134498

Merged

build-analysis Bot mentioned this pull request Sep 23, 2026

System.Net.Security.Tests.CertificateValidationRemoteServer.ConnectWithRevocation_WithCallback fails with Assert.Contains() Failure #134230

Open

pavelsavara marked this pull request as ready for review September 25, 2026 10:09

Copilot AI lite review requested due to automatic review settings September 25, 2026 10:09

pavelsavara requested review from akoeplinger, lewing, maraf, steveisok and vitek-karas as code owners September 25, 2026 10:09

Copilot started reviewing on behalf of pavelsavara September 25, 2026 10:09 View session

Copilot AI reviewed Sep 25, 2026

View reviewed changes

maraf reviewed Sep 25, 2026

View reviewed changes

Comment thread src/mono/browser/build/BrowserWasmApp.CoreCLR.targets Outdated

akoeplinger reviewed Sep 25, 2026

View reviewed changes

Copilot AI review requested due to automatic review settings September 25, 2026 16:26

Copilot started reviewing on behalf of pavelsavara September 25, 2026 16:27 View session

Copilot AI reviewed Sep 25, 2026

View reviewed changes

Comment thread src/mono/mono/utils/mono-threads-wasm.c

Comment on lines +201 to 202

// emscripten links with --stack-first at -O0, which puts the stack at the start of the linear memory, so staddr can legitimately be NULL

g_assert (*stsize != (size_t)-1);

Navigation Menu

[browser] Fix Debug-only startup failures: stack-first assert, incoming Module API, preRun function form - #134527

[browser] Fix Debug-only startup failures: stack-first assert, incoming Module API, preRun function form#134527
pavelsavara wants to merge 7 commits into
dotnet:mainfrom
pavelsavara:browser_fix_debug

pavelsavara commented Sep 23, 2026 •

edited

Loading

Uh oh!

azure-pipelines Bot commented Sep 23, 2026

Uh oh!

dotnet-policy-service Bot commented Sep 23, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

pavelsavara Sep 25, 2026

Uh oh!

Uh oh!

akoeplinger Sep 25, 2026

Uh oh!

pavelsavara Sep 25, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

		// emscripten links with --stack-first at -O0, which puts the stack at the start of the linear memory, so staddr can legitimately be NULL
		g_assert (*stsize != (size_t)-1);

Conversation

pavelsavara commented Sep 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

1. Mono MT asserts on the stack bounds at startup

2. Module.wasmMemory was supplied but wasmMemory not included in INCOMING_MODULE_JS_API

3. TypeError: (Module.preRun || []) is not iterable

Verification

Uh oh!

azure-pipelines Bot commented Sep 23, 2026

Uh oh!

dotnet-policy-service Bot commented Sep 23, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot review overview

🟡 Changes recommended

Uh oh!

pavelsavara Sep 25, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

akoeplinger Sep 25, 2026

Choose a reason for hiding this comment

Uh oh!

pavelsavara Sep 25, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot review overview

🟡 Changes recommended

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

pavelsavara commented Sep 23, 2026 •

edited

Loading

2. `Module.wasmMemory was supplied but wasmMemory not included in INCOMING_MODULE_JS_API`

3. `TypeError: (Module.preRun || []) is not iterable`