wasmtime / issue #13397 wasip3: `sockets-tcp-listen::test... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #13397 wasip3: `sockets-tcp-listen::test...

Wasmtime GitHub notifications bot (May 16 2026 at 12:55):

Summary

The upstream wasi-testsuite fixture wasm32-wasip3/sockets-tcp-listen (tests/rust/wasm32-wasip3/src/bin/sockets-tcp-listen.rs's test_inherited_properties) panics on wasmtime 44.0.1 (first stable release with -Sp3 support). The fixture binds a TCP listener, accepts an inbound connection, and asserts that every reachable socket option on the accepted socket equals the same option on the listening socket. wasmtime's get_send_buffer_size for the accepted socket reports a different value from the listener — Ok(1313280) vs Ok(8192) — and assert_eq! panics.

Reproduction
cd tests/rust/wasm32-wasip3 && make build && cd -
wasmtime -Wcomponent-model-async -Sp3,inherit-network \
    tests/rust/testsuite/wasm32-wasip3/sockets-tcp-listen.wasm
Output (trimmed):
thread '<unnamed>' (1) panicked at src/bin/sockets-tcp-listen.rs:53:13:
assertion `left == right` failed
  left: Ok(1313280)
 right: Ok(8192)
…
   13:   0x3703 - sockets_tcp_listen…!sockets_tcp_listen…::test_inherited_properties::{closure#0}::{closure#0}
…
    1: wasm trap: wasm `unreachable` instruction executed
The asserting code (tests/wasi-testsuite tests/rust/wasm32-wasip3/src/bin/sockets-tcp-listen.rs:36-58):
let mut accept = sock.listen().unwrap();
futures::join!(
    async {
        let next = accept.next().await.unwrap();
        assert_eq!(next.get_address_family(), sock.get_address_family());
        assert_eq!(next.get_keep_alive_enabled(), sock.get_keep_alive_enabled());
        assert_eq!(next.get_keep_alive_idle_time(), sock.get_keep_alive_idle_time());
        assert_eq!(next.get_keep_alive_interval(), sock.get_keep_alive_interval());
        assert_eq!(next.get_keep_alive_count(), sock.get_keep_alive_count());
        assert_eq!(next.get_hop_limit(), sock.get_hop_limit());
        assert_eq!(next.get_receive_buffer_size(), sock.get_receive_buffer_size());
        assert_eq!(next.get_send_buffer_size(), sock.get_send_buffer_size());  // ← panics here
    },
    async { client.connect(local_addr).await.unwrap(); }
);
Cross-runtime parity

The same fixture passes on the WAMR-Zig WASIp3 host (40 / 40 wasm32-wasip3 fixtures pass, this one included). The WAMR host caches the user-set buffer size on the listening socket rep and propagates that exact value into the accepted socket's rep, regardless of what the Linux kernel may have autotuned SO_SNDBUF to behind its back (which is the source of the 1313280 value wasmtime reports — Linux applies tcp_wmem autotuning on accepted sockets independently of the listener's stored value).

If the WIT contract for tcp-socket.[get/set]-send-buffer-size is "the host caches the last value the guest set and returns it unchanged on get", wasmtime 44 needs to do the same caching. If the contract allows the kernel to silently override the stored value (a reasonable interpretation since SO_SNDBUF is autotuned by Linux), then the fixture's assert_eq! is too strict and should be relaxed (or dropped) for the buffer-size pair. Either way it's a wasmtime-side delta from the only other WASIp3 runtime that's currently passing the full corpus.

Why this matters

Same as #11342 — this is one of four wasm32-wasip3 fixtures that fail on stock wasmtime 44.0.1 but pass on the WAMR-Zig host; tracked in cataggar/wamr#583 C1.

Environment

wasmtime 44.0.1 (f302ebd6b 2026-04-30)

wasi-testsuite 40c1f7d tests/rust/testsuite/wasm32-wasip3/sockets-tcp-listen.wasm

Linux 6.x aarch64

Wasmtime GitHub notifications bot (May 19 2026 at 14:03):

saulecabrera commented on issue #13397:

The failing asserts are removed here https://github.com/WebAssembly/wasi-testsuite/pull/227/changes, as part of the conclusion reached in https://github.com/bytecodealliance/wasmtime/issues/12561

Wasmtime GitHub notifications bot (May 21 2026 at 16:10):

fitzgen commented on issue #13397:

The failing asserts are removed here https://github.com/WebAssembly/wasi-testsuite/pull/227/changes, as part of the conclusion reached in #12561

Does that mean this issue should be closed?

Wasmtime GitHub notifications bot (May 21 2026 at 16:15):

saulecabrera closed issue #13397:

Summary

The upstream wasi-testsuite fixture wasm32-wasip3/sockets-tcp-listen (tests/rust/wasm32-wasip3/src/bin/sockets-tcp-listen.rs's test_inherited_properties) panics on wasmtime 44.0.1 (first stable release with -Sp3 support). The fixture binds a TCP listener, accepts an inbound connection, and asserts that every reachable socket option on the accepted socket equals the same option on the listening socket. wasmtime's get_send_buffer_size for the accepted socket reports a different value from the listener — Ok(1313280) vs Ok(8192) — and assert_eq! panics.

Reproduction
cd tests/rust/wasm32-wasip3 && make build && cd -
wasmtime -Wcomponent-model-async -Sp3,inherit-network \
    tests/rust/testsuite/wasm32-wasip3/sockets-tcp-listen.wasm
Output (trimmed):
thread '<unnamed>' (1) panicked at src/bin/sockets-tcp-listen.rs:53:13:
assertion `left == right` failed
  left: Ok(1313280)
 right: Ok(8192)
…
   13:   0x3703 - sockets_tcp_listen…!sockets_tcp_listen…::test_inherited_properties::{closure#0}::{closure#0}
…
    1: wasm trap: wasm `unreachable` instruction executed
The asserting code (tests/wasi-testsuite tests/rust/wasm32-wasip3/src/bin/sockets-tcp-listen.rs:36-58):
let mut accept = sock.listen().unwrap();
futures::join!(
    async {
        let next = accept.next().await.unwrap();
        assert_eq!(next.get_address_family(), sock.get_address_family());
        assert_eq!(next.get_keep_alive_enabled(), sock.get_keep_alive_enabled());
        assert_eq!(next.get_keep_alive_idle_time(), sock.get_keep_alive_idle_time());
        assert_eq!(next.get_keep_alive_interval(), sock.get_keep_alive_interval());
        assert_eq!(next.get_keep_alive_count(), sock.get_keep_alive_count());
        assert_eq!(next.get_hop_limit(), sock.get_hop_limit());
        assert_eq!(next.get_receive_buffer_size(), sock.get_receive_buffer_size());
        assert_eq!(next.get_send_buffer_size(), sock.get_send_buffer_size());  // ← panics here
    },
    async { client.connect(local_addr).await.unwrap(); }
);
Cross-runtime parity

The same fixture passes on the WAMR-Zig WASIp3 host (40 / 40 wasm32-wasip3 fixtures pass, this one included). The WAMR host caches the user-set buffer size on the listening socket rep and propagates that exact value into the accepted socket's rep, regardless of what the Linux kernel may have autotuned SO_SNDBUF to behind its back (which is the source of the 1313280 value wasmtime reports — Linux applies tcp_wmem autotuning on accepted sockets independently of the listener's stored value).

If the WIT contract for tcp-socket.[get/set]-send-buffer-size is "the host caches the last value the guest set and returns it unchanged on get", wasmtime 44 needs to do the same caching. If the contract allows the kernel to silently override the stored value (a reasonable interpretation since SO_SNDBUF is autotuned by Linux), then the fixture's assert_eq! is too strict and should be relaxed (or dropped) for the buffer-size pair. Either way it's a wasmtime-side delta from the only other WASIp3 runtime that's currently passing the full corpus.

Why this matters

Same as #11342 — this is one of four wasm32-wasip3 fixtures that fail on stock wasmtime 44.0.1 but pass on the WAMR-Zig host; tracked in cataggar/wamr#583 C1.

Environment

wasmtime 44.0.1 (f302ebd6b 2026-04-30)

wasi-testsuite 40c1f7d tests/rust/testsuite/wasm32-wasip3/sockets-tcp-listen.wasm

Linux 6.x aarch64

Wasmtime GitHub notifications bot (May 21 2026 at 16:15):

saulecabrera commented on issue #13397:

I'll close it as a duplicate of https://github.com/bytecodealliance/wasmtime/issues/12561.

Last updated: Jun 01 2026 at 09:49 UTC