Skip to content

[wasi] Bump WASI SDK to 34.0 and wasmtime to 49.0.1 - #134992

Merged
lewing merged 1 commit into
dotnet:mainfrom
lewing:lewing-wasi-sdk-34-bump
Oct 1, 2026
Merged

[wasi] Bump WASI SDK to 34.0 and wasmtime to 49.0.1#134992
lewing merged 1 commit into
dotnet:mainfrom
lewing:lewing-wasi-sdk-34-bump

Conversation

@lewing

@lewing lewing commented Sep 30, 2026

Copy link
Copy Markdown
Member

wasi-sdk 34 includes the wasi-libc fix for WebAssembly/wasi-libc#861 (pread copying from an uninitialized result on failure), which caused the out-of-bounds memory access in #134957.

Changes required by the new wasi-libc:

  • descriptor_table_get_ref was replaced by the refcounted descriptor_table_get; update SystemNative_GetWasiSocketDescriptor and add the leading refcnt field to the managed tcp/udp socket mirrors.
  • wasi-libc now uses WASI 0.2.12 and imports wasi:cli/exit exit-with-code, which wasmtime supports by default starting with 46, so bump the pinned wasmtime to 49.0.1.
  • With exit-with-code available, make the WASI hosts (corerun, wasihost, Mono main.c) exit() with the real code and remove the "WASM EXIT " / DOTNET_WASI_PRINT_EXIT_CODE stderr marker and its consumers (CLRTest launcher, tests.wasi.targets, WasmAppHost, samples).

Also pass the acquired WASI_SDK_PATH to the CoreCLR native build so a preinstalled SDK of a different version (e.g. in CI containers) isn't used, and update the wasm32-wasi comment to wasm32-wasip2 (the wasm32-wasi/wasm32-wasi-threads targets were removed in wasi-sdk 34).

@lewing
[wasi] Bump WASI SDK to 34.0 and wasmtime to 49.0.1
c850f0c 
wasi-sdk 34 includes the wasi-libc fix for WebAssembly/wasi-libc#861
(pread copying from an uninitialized result on failure), which caused
the out-of-bounds memory access in dotnet#134957.

Changes required by the new wasi-libc:
- descriptor_table_get_ref was replaced by the refcounted
  descriptor_table_get; update SystemNative_GetWasiSocketDescriptor and
  add the leading refcnt field to the managed tcp/udp socket mirrors.
- wasi-libc now uses WASI 0.2.12 and imports wasi:cli/exit
  exit-with-code, which wasmtime supports by default starting with 46,
  so bump the pinned wasmtime to 49.0.1.
- With exit-with-code available, make the WASI hosts (corerun,
  wasihost, Mono main.c) exit() with the real code and remove the
  "WASM EXIT <n>" / DOTNET_WASI_PRINT_EXIT_CODE stderr marker and its
  consumers (CLRTest launcher, tests.wasi.targets, WasmAppHost, samples).

Also pass the acquired WASI_SDK_PATH to the CoreCLR native build so a
preinstalled SDK of a different version (e.g. in CI containers) isn't
used, and update the wasm32-wasi comment to wasm32-wasip2 (the
wasm32-wasi/wasm32-wasi-threads targets were removed in wasi-sdk 34).

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@azure-pipelines

azure-pipelines Bot commented Sep 30, 2026

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

@lewing lewing added arch-wasm WebAssembly architecture os-wasi Related to WASI variant of arch-wasm labels Sep 30, 2026
@dotnet-policy-service

dotnet-policy-service Bot commented Sep 30, 2026

Copy link
Copy Markdown
Contributor

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

This was referenced Oct 1, 2026
Open
Open
Open
Open
Open
@pavelsavara

pavelsavara commented Oct 1, 2026

Copy link
Copy Markdown
Member

I guess we have the same issue in Net11

@lewing

lewing commented Oct 1, 2026

Copy link
Copy Markdown
Member Author

/ba-g failure is known and tracked

@lewing
lewing merged commit cd0e2ff into dotnet:main Oct 1, 2026
226 of 230 checks passed
lewing added a commit to lewing/runtime that referenced this pull request Oct 1, 2026
@lewing
[wasi] Remove the InconsistentFileAccessThrows quarantine
aa1f3b5 
WASI SDK 34 (dotnet#134992) includes the wasi-libc pread fix (WebAssembly/wasi-libc#862) for the memory corruption tracked by dotnet#134957.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This was referenced Oct 1, 2026
Merged
Closed
Merged
lewing added a commit to lewing/runtime that referenced this pull request Oct 1, 2026
@lewing
[wasi] Remove the InconsistentFileAccessThrows quarantine
ceab2d5 
WASI SDK 34 (dotnet#134992) includes the wasi-libc pread fix (WebAssembly/wasi-libc#862) for the memory corruption tracked by dotnet#134957.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
lewing added a commit to lewing/runtime that referenced this pull request Oct 2, 2026
@lewing
[wasi] Remove the InconsistentFileAccessThrows quarantine
3325421 
WASI SDK 34 (dotnet#134992) includes the wasi-libc pread fix (WebAssembly/wasi-libc#862) for the memory corruption tracked by dotnet#134957.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@dotnet-maestro dotnet-maestro Bot mentioned this pull request Oct 2, 2026
Merged
@dotnet-milestone-bot dotnet-milestone-bot Bot added this to the 12.0-preview1 milestone Oct 2, 2026
lewing added a commit that referenced this pull request Oct 2, 2026
@lewing
[wasi] Return parsed IP literals from Dns.GetHostAddressesAsync (#135033
eb80f4f 
)

On WASI, `Dns.GetHostAddressesAsync("127.0.0.1",
AddressFamily.InterNetworkV6)` throws `SocketException: Name does not
resolve`, while the synchronous `Dns.GetHostAddresses` returns an empty
array.

## Cause

`GetHostAddresses` returns parsed IP literals directly, filtered by
address family, on every platform. `GetHostEntryOrAddressesCoreAsync`
takes that shortcut only when `NameResolutionPal.SupportsGetNameInfo` is
true, and that is `!OperatingSystem.IsWasi()`. So on WASI the async path
sends the IP literal to `getaddrinfo` with a mismatched family. Since
#134992 (wasmtime 49.0.1 / wasi-sdk 34) that returns `EAI_NONAME`.

## Fix

`SupportsGetNameInfo` matters only when a reverse lookup is needed. When
the caller wants just the parsed IP (`justReturnParsedIp`), the shortcut
now runs regardless:

```csharp
if ((justReturnParsedIp || NameResolutionPal.SupportsGetNameInfo) && IPAddress.TryParse(hostName, out IPAddress? ipAddress))
```

Effect on each caller:
- **`GetHostAddressesAsync` (all overloads) and
`BeginGetHostAddresses`** (`justReturnParsedIp: true`): on WASI these
now match sync `GetHostAddresses`. That includes the `ArgumentException`
for `0.0.0.0`/`::`.
- **`BeginGetHostByName`** (`justReturnParsedIp: true`): now returns
`CreateHostEntryForAddress`, matching sync `GetHostByName`.
`EndGetHostByName` still throws PNSE on WASI.
- **`GetHostEntryAsync(string)`, `BeginGetHostEntry(string)`,
`BeginResolve`** (`justReturnParsedIp: false`): no change. These need
`getnameinfo`, so they stay gated on WASI.
- **Non-WASI platforms:** no change, because `SupportsGetNameInfo` is
true there.

The other `SupportsGetNameInfo`-gated IP-literal sites,
`GetHostEntry(string, AddressFamily)` and `Resolve`, perform reverse
lookups. Their async counterparts use `justReturnParsedIp: false`, so
sync and async already behave the same, and those sites are unchanged.

## Tests


`GetHostAddressesTest.DnsGetHostAddresses_IPStringAndIncorrectFamily_ReturnsNoIPs`
already covers this through its `useAsync: True` rows, so no new test is
added.

Follow-up: #134813 splits that theory and adds
`[ActiveIssue("#135030",
TestPlatforms.Wasi)]` to the async variant. Once both PRs merge, that
`ActiveIssue` should be removed.

## Validation

Validated locally on macOS arm64, on top of `beb346acc72`.

- WASI baseline: `./build.sh -s clr+libs+host+packs -os wasi -arch wasm
-rf CoreCLR -c Release` succeeded.
- WASI tests: `./dotnet.sh build
src/libraries/System.Net.NameResolution/tests/FunctionalTests/System.Net.NameResolution.Functional.Tests.csproj
/t:Test /p:TargetOS=wasi /p:TargetArchitecture=wasm
/p:RuntimeFlavor=CoreCLR /p:Configuration=Release`
- **Without the fix:** 142 run, 88 passed, 3 failed, 51 skipped. Both
`useAsync: True` rows of
`DnsGetHostAddresses_IPStringAndIncorrectFamily_ReturnsNoIPs` failed
with `SocketException: Name does not resolve`.
- **With the fix:** 142 run, 89 passed, 2 failed, 51 skipped. All four
`IPStringAndIncorrectFamily` rows passed.
- Desktop (osx-arm64): after `./build.sh clr+libs -rc release`,
`./dotnet.sh build
src/libraries/System.Net.NameResolution/tests/FunctionalTests/System.Net.NameResolution.Functional.Tests.csproj
/t:Test` ran 195 tests with 3 failures and 11 skipped. All four
`IPStringAndIncorrectFamily` rows passed.

All remaining failures, on both WASI and desktop, are
`*_BadName_Throws`/`DnsGetHostEntry_BadName_ThrowsSocketException`. They
are environmental: the dev machine's DNS search suffix resolves
`BadName`, as `dscacheutil -q host -a name BadName` confirms by
returning `badname.file.core.windows.net`. They use non-IP names, so
this change doesn't touch them.

Resolves #135030

> [!NOTE]
> This PR description was generated with the help of GitHub Copilot.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
lewing added a commit to lewing/runtime that referenced this pull request Oct 3, 2026
@lewing
[wasi] Remove the InconsistentFileAccessThrows quarantine
33b2b3b 
WASI SDK 34 (dotnet#134992) includes the wasi-libc pread fix (WebAssembly/wasi-libc#862) for the memory corruption tracked by dotnet#134957.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
lewing added a commit that referenced this pull request Oct 13, 2026
@lewing
Reconfigure native CMake builds from scratch when the compiler inputs…
bcf4adb 
… change (#135028)

CMake detects the compiler only on a build directory's first configure,
so later changes to the toolchain file, `CC`/`CXX` or `emcmake` are
ignored. Since the WASI SDK and emsdk moved to versioned tool cache
directories, every SDK bump leaves existing local build directories
using the old compiler. After #134992 that caused link errors like
`undefined symbol: __wasilibc_descriptor_deallocate`. CI configures
fresh and is unaffected.

`gen-buildsys.sh`/`.cmd` now record the inputs that select the compiler
in `<build dir>/cmake_compiler_inputs.txt`: the toolchain file
(environment variable and `-DCMAKE_TOOLCHAIN_FILE` arguments), `CC`,
`CXX`, the first line of `$CC --version` (catches an Xcode update or
package upgrade behind the same path), the resolved cmake command
including wrappers like `emcmake`, and on Windows `VCToolsInstallDir`.
If a build directory's record differs, the script runs the `clean`
target and then configures with `--fresh`. The clean is needed because
ninja/make rebuild an object only when its command line changes, which
doesn't happen when the compiler behind the same path is replaced (e.g.
an Xcode update). Existing build directories have no record yet, so the
first build with this change only reconfigures (`--fresh`, no clean).

Validated locally on macOS. WASI SDK 33.0 → 34.0 (native libraries and
CoreCLR), a `CLR_CC` host compiler switch, an Xcode → Command Line Tools
switch, and an emsdk version change all reconfigured with the new
compiler, and unchanged builds stayed incremental. `gen-buildsys.cmd`
wasn't run (no Windows host).

> [!NOTE]
> This PR description was generated with GitHub Copilot.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@lewing lewing mentioned this pull request Oct 16, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@maraf maraf maraf approved these changes
@akoeplinger akoeplinger Awaiting requested review from akoeplinger akoeplinger is a code owner
@pavelsavara pavelsavara Awaiting requested review from pavelsavara pavelsavara is a code owner

Assignees

@lewing lewing

Labels

arch-wasm WebAssembly architecture area-Build-mono os-wasi Related to WASI variant of arch-wasm

Projects

None yet

Milestone

12.0-preview1

Development

Successfully merging this pull request may close these issues.

3 participants

@lewing @pavelsavara @maraf