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
Open
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>
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