Stream: git-wasmtime

Topic: wasmtime / issue #15088 C API: wasm_valtype_kind() aborts...

view this post on Zulip Wasmtime GitHub notifications bot (Oct 30 2026 at 14:41):

o-murphy opened issue #15088:

Thanks for filing a bug report! Please fill out the TODOs below.

Note: if you want to report a security issue, please read our security policy!

Test Case

No Wasm file is needed; the C API call alone reproduces it:

#include <stdio.h>
#include <wasm.h>
#include <wasmtime.h>

int main(void) {
  wasm_valtype_t *t = wasmtime_wasm_valtype_v128();
  printf("calling wasm_valtype_kind on a v128 valtype...\n");
  fflush(stdout);
  wasm_valkind_t k = wasm_valtype_kind(t); /* aborts */
  printf("kind = %d\n", (int)k);
  wasm_valtype_delete(t);
  return 0;
}

Steps to Reproduce

Expected Results

wasm_valtype_kind() does not take the host process down. wasm.h's wasm_valkind_t has no v128
member, so either a documented Wasmtime-specific value is returned for v128, or the function's
documentation says it must not be called on v128 types and points to wasmtime_valtype_new(),
which already handles v128 (wasmtime_valtype_t::V128) and is what the C++ API uses.

Actual Results

The process aborts:

calling wasm_valtype_kind on a v128 valtype...
`support for v128 ` is not implemented
Aborted (exit code 134)

The cause is the // TODO arm in crates/c-api/src/types/val.rs:

pub extern "C" fn wasm_valtype_kind(vt: &wasm_valtype_t) -> wasm_valkind_t {
    match vt {
        ...
        // TODO
        ValType::V128 => crate::abort("support for v128 "),

It is still there on main (81231fd, 2026-10-30).

Versions and Environment

Wasmtime version or commit: 50.0.1 (the libwasmtime shipped in the wasmtime-py 50.0.1 wheel); the
same code is on main at 81231fd

Operating system: Linux (Ubuntu 24.04)

Architecture: x86_64

Extra Info

Embedders that inspect function or global types with the standard wasm.h API hit this as soon as a
module uses v128 in a signature. wasmtime-py 50.0.1 does (its ValType.__eq__/__str__ call
wasm_valtype_kind()), so calling an export with a v128 parameter aborts the Python interpreter:
bytecodealliance/wasmtime-py#<n>. We found it while running the WebAssembly spec suite
(test/core/simd) through wasmtime-py as a reference implementation.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 30 2026 at 14:41):

o-murphy added the bug label to Issue #15088.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 30 2026 at 14:46):

o-murphy edited issue #15088:

Thanks for filing a bug report! Please fill out the TODOs below.

Note: if you want to report a security issue, please read our security policy!

Test Case

No Wasm file is needed; the C API call alone reproduces it:

#include <stdio.h>
#include <wasm.h>
#include <wasmtime.h>

int main(void) {
  wasm_valtype_t *t = wasmtime_wasm_valtype_v128();
  printf("calling wasm_valtype_kind on a v128 valtype...\n");
  fflush(stdout);
  wasm_valkind_t k = wasm_valtype_kind(t); /* aborts */
  printf("kind = %d\n", (int)k);
  wasm_valtype_delete(t);
  return 0;
}

Steps to Reproduce

Expected Results

wasm_valtype_kind() does not take the host process down. wasm.h's wasm_valkind_t has no v128
member, so either a documented Wasmtime-specific value is returned for v128, or the function's
documentation says it must not be called on v128 types and points to wasmtime_valtype_new(),
which already handles v128 (wasmtime_valtype_t::V128) and is what the C++ API uses.

Actual Results

The process aborts:

calling wasm_valtype_kind on a v128 valtype...
`support for v128 ` is not implemented
Aborted (exit code 134)

The cause is the // TODO arm in crates/c-api/src/types/val.rs:

pub extern "C" fn wasm_valtype_kind(vt: &wasm_valtype_t) -> wasm_valkind_t {
    match vt {
        ...
        // TODO
        ValType::V128 => crate::abort("support for v128 "),

It is still there on main (81231fd, 2026-10-30).

Versions and Environment

Wasmtime version or commit: 50.0.1 (the libwasmtime shipped in the wasmtime-py 50.0.1 wheel); the
same code is on main at 81231fd

Operating system: Linux (Ubuntu 24.04)

Architecture: x86_64

Extra Info

Embedders that inspect function or global types with the standard wasm.h API hit this as soon as a
module uses v128 in a signature. wasmtime-py 50.0.1 does (its ValType.__eq__/__str__ call
wasm_valtype_kind()), so calling an export with a v128 parameter aborts the Python interpreter:
bytecodealliance/wasmtime-py#348. We found it while running the WebAssembly spec suite
(test/core/simd) through wasmtime-py as a reference implementation.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 30 2026 at 14:50):

alexcrichton commented on issue #15088:

Thanks for the report, but this is currently expected behavior because wasm.h lags quite a bit behind the standard itself. The only option here really is to make sure we've got a function that works (e.g. wasmtime_valtype_new). I agree though the documentation could probably be more clear in this respect.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 30 2026 at 14:50):

alexcrichton added the wasmtime:c-api label to Issue #15088.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 30 2026 at 14:50):

alexcrichton added the wasmtime:docs label to Issue #15088.

Last updated: Oct 31 2026 at 23:03 UTC