wasmtime / issue #10279 musl-c-api Version of Library Not... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #10279 musl-c-api Version of Library Not...

Wasmtime GitHub notifications bot (Feb 23 2025 at 21:19):

cernydav added the bug label to Issue #10279.

Wasmtime GitHub notifications bot (Feb 23 2025 at 21:19):

TL;DR
Starting with Wasmtime version 27.0.0, the musl-c-api build fails on Alpine Linux, causing a memory panic error. The last known working version is 26.0.1.

Steps to Reproduce
Install Wasmtime using Alpine's edge testing repository:
FROM  mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS base
RUN apk add --update --no-cache --repository=http://dl-cdn.alpinelinux.org/alpine/edge/testing/ libwasmtime #not working V30
Invoke Wasmtime from your code: For instance, use the dotnet-opa-wasm library sample (see dotnet-opa-wasm sample).

Encounter the error:
thread '<unnamed>' panicked at crates/c-api/src/types/memory.rs:89:14:
called `Result::unwrap()` on an `Err` value: shared memories must have a maximum size
Test Case

The musl-c-api build of the Wasmtime library, when deployed on Alpine Linux distributions, begins to fail starting with version 27.0.0. The last version that worked correctly is 26.0.1. This issue likely stems from a breaking change in newer versions that the musl environment on Alpine cannot handle.

Key Observations:

Alpine Linux vs. Debian:

Alpine Linux: Requires a statically linked musl version of the library, which fails from version 27.0.0 onward.

Debian-based distributions: Work normally with the latest version because they use the dynamically linked version of Wasmtime.

Memory Panic Error:

The application crashes with an error indicating that "shared memories must have a maximum size" due to an unhandled Err value when unwrap() is called.

Configuration Settings Failure:

Attempts to set memory limits via code (e.g., using the opa-wasm library) also fail. For example, invoking wasmtime_config_static_memory_maximum_size_set results in:

System.EntryPointNotFoundException: Unable to find an entry point named 'wasmtime_config_static_memory_maximum_size_set' in shared library 'wasmtime'.

Edge Repository Issue:

The version available from Alpine’s edge testing repository (e.g., version 30) exhibits this issue, reinforcing the need to revert to a previously working version.

Expected Results

The application should run without crashing, with Wasmtime functioning as expected.

Actual Results

Error Stack Trace (Version 29.0.0)
09:52:55:422    Loaded '/app/bin/Debug/net8.0/Opa.Wasm.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
09:52:55:673    thread '<unnamed>' panicked at crates/c-api/src/types/memory.rs:89:14:
09:52:55:673    called `Result::unwrap()` on an `Err` value: shared memories must have a maximum size
09:52:55:673
09:52:55:673    Stack backtrace:
09:52:55:673       0: anyhow::error::<impl anyhow::Error>::msg
09:52:55:673    stack backtrace:
09:52:55:673       0:     0x7f494e9a5a0a - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h4e2ed00da9626c89
09:52:55:673       1:     0x7f494e9cac33 - core::fmt::write::h1e2817ad6effb3a8
09:52:55:673       2:     0x7f494e9a2233 - std::io::Write::write_fmt::h2248a88e59fb6993
09:52:55:673       3:     0x7f494e9a5852 - std::sys::backtrace::BacktraceLock::print::he72565f9e0b2846f
09:52:55:673       4:     0x7f494e9a6887 - std::panicking::default_hook::{{closure}}::hd88bc1072bff8016
09:52:55:673       5:     0x7f494e9a66cd - std::panicking::default_hook::h2975aaf8fe1bdbb2
09:52:55:673       6:     0x7f494e9a6e57 - std::panicking::rust_panic_with_hook::h54f358af0528b0ac
09:52:55:673       7:     0x7f494e9a6cea - std::panicking::begin_panic_handler::{{closure}}::h8022c92830c406a8
09:52:55:673       8:     0x7f494e9a5ee9 - std::sys::backtrace::__rust_end_short_backtrace::h4b072f3484fb4e42
09:52:55:673       9:     0x7f494e9a697c - rust_begin_unwind
09:52:55:673      10:     0x7f494e0622f0 - core::panicking::panic_fmt::h8143c7df49e27964
09:52:55:673      11:     0x7f494e062736 - core::result::unwrap_failed::h77d9a525433959c1
09:52:55:673      12:     0x7f494e090d6e - wasmtime_memorytype_new
09:52:55:673      13:     0x7f89f181d699 - <unknown>
09:52:56:267    The program 'dotnet' has exited with code 0 (0x0).
Versions and Environment

Any newer musl-c-api newer from 26.0.0

mcr.microsoft.com/dotnet/aspnet:8.0-alpine

Extra Info

Installing and testing other versions can be done by following definition
# RUN apk add --update --no-cache --repository=http://dl-cdn.alpinelinux.org/alpine/edge/testing/ libwasmtime  # Not working: V30
# ARG WASMTIME_VERSION=30.0.1
# ARG WASMTIME_VERSION=27.0.0
ARG WASMTIME_VERSION=26.0.1  # Last working version
RUN wget https://github.com/bytecodealliance/wasmtime/releases/download/v${WASMTIME_VERSION}/wasmtime-v${WASMTIME_VERSION}-x86_64-musl-c-api.tar.xz
RUN tar -xJvf wasmtime-v${WASMTIME_VERSION}-x86_64-musl-c-api.tar.xz -C /usr
RUN cp -r /usr/wasmtime-v${WASMTIME_VERSION}-x86_64-musl-c-api/include/. /usr/include
RUN cp -r /usr/wasmtime-v${WASMTIME_VERSION}-x86_64-musl-c-api/lib/. /usr/lib

Wasmtime GitHub notifications bot (Feb 24 2025 at 15:58):

alexcrichton commented on issue #10279:

Would you be able to clarify how you're using the Wasmtime C API? Is it through wasmtime-dotnet for example? If so, that repository looks like it hasn't been updated past 22.0.0 and I believe C API signatures have changed in the meantime which might be why you're seeing this. If you're not using wasmtime-dotnet this may mean that the ABI signatures are being mismatched though?

Wasmtime GitHub notifications bot (Feb 24 2025 at 20:49):

cernydav commented on issue #10279:

Yes, that is correct. I’m using it through Opa.Wasm, which depends on wasmtime-dotnet. I believe the proper solution is to first fix this library so that it allows setting the required memory limits. I’m reporting this issue for two reasons. First, there appears to be a breaking change in the behavior of the current version of the wasmtime library; and second, this issue might need to be escalated further up the dependency chain, possibly even to the Opa.Wasm documentation.

![Image](https://github.com/user-attachments/assets/b7d7d97c-2d79-4386-928f-ce987a098c2b)

Wasmtime GitHub notifications bot (Feb 24 2025 at 21:07):

alexcrichton closed issue #10279:

TL;DR
Starting with Wasmtime version 27.0.0, the musl-c-api build fails on Alpine Linux, causing a memory panic error. The last known working version is 26.0.1.

Steps to Reproduce
Install Wasmtime using Alpine's edge testing repository:
FROM  mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS base
RUN apk add --update --no-cache --repository=http://dl-cdn.alpinelinux.org/alpine/edge/testing/ libwasmtime #not working V30
Invoke Wasmtime from your code: For instance, use the dotnet-opa-wasm library sample (see dotnet-opa-wasm sample).

Encounter the error:
thread '<unnamed>' panicked at crates/c-api/src/types/memory.rs:89:14:
called `Result::unwrap()` on an `Err` value: shared memories must have a maximum size
Test Case

The musl-c-api build of the Wasmtime library, when deployed on Alpine Linux distributions, begins to fail starting with version 27.0.0. The last version that worked correctly is 26.0.1. This issue likely stems from a breaking change in newer versions that the musl environment on Alpine cannot handle.

Key Observations:

Alpine Linux vs. Debian:

Alpine Linux: Requires a statically linked musl version of the library, which fails from version 27.0.0 onward.

Debian-based distributions: Work normally with the latest version because they use the dynamically linked version of Wasmtime.

Memory Panic Error:

The application crashes with an error indicating that "shared memories must have a maximum size" due to an unhandled Err value when unwrap() is called.

Configuration Settings Failure:

Attempts to set memory limits via code (e.g., using the opa-wasm library) also fail. For example, invoking wasmtime_config_static_memory_maximum_size_set results in:

System.EntryPointNotFoundException: Unable to find an entry point named 'wasmtime_config_static_memory_maximum_size_set' in shared library 'wasmtime'.

Edge Repository Issue:

The version available from Alpine’s edge testing repository (e.g., version 30) exhibits this issue, reinforcing the need to revert to a previously working version.

Expected Results

The application should run without crashing, with Wasmtime functioning as expected.

Actual Results

Error Stack Trace (Version 29.0.0)
09:52:55:422    Loaded '/app/bin/Debug/net8.0/Opa.Wasm.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
09:52:55:673    thread '<unnamed>' panicked at crates/c-api/src/types/memory.rs:89:14:
09:52:55:673    called `Result::unwrap()` on an `Err` value: shared memories must have a maximum size
09:52:55:673
09:52:55:673    Stack backtrace:
09:52:55:673       0: anyhow::error::<impl anyhow::Error>::msg
09:52:55:673    stack backtrace:
09:52:55:673       0:     0x7f494e9a5a0a - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h4e2ed00da9626c89
09:52:55:673       1:     0x7f494e9cac33 - core::fmt::write::h1e2817ad6effb3a8
09:52:55:673       2:     0x7f494e9a2233 - std::io::Write::write_fmt::h2248a88e59fb6993
09:52:55:673       3:     0x7f494e9a5852 - std::sys::backtrace::BacktraceLock::print::he72565f9e0b2846f
09:52:55:673       4:     0x7f494e9a6887 - std::panicking::default_hook::{{closure}}::hd88bc1072bff8016
09:52:55:673       5:     0x7f494e9a66cd - std::panicking::default_hook::h2975aaf8fe1bdbb2
09:52:55:673       6:     0x7f494e9a6e57 - std::panicking::rust_panic_with_hook::h54f358af0528b0ac
09:52:55:673       7:     0x7f494e9a6cea - std::panicking::begin_panic_handler::{{closure}}::h8022c92830c406a8
09:52:55:673       8:     0x7f494e9a5ee9 - std::sys::backtrace::__rust_end_short_backtrace::h4b072f3484fb4e42
09:52:55:673       9:     0x7f494e9a697c - rust_begin_unwind
09:52:55:673      10:     0x7f494e0622f0 - core::panicking::panic_fmt::h8143c7df49e27964
09:52:55:673      11:     0x7f494e062736 - core::result::unwrap_failed::h77d9a525433959c1
09:52:55:673      12:     0x7f494e090d6e - wasmtime_memorytype_new
09:52:55:673      13:     0x7f89f181d699 - <unknown>
09:52:56:267    The program 'dotnet' has exited with code 0 (0x0).
Versions and Environment

Any newer musl-c-api newer from 26.0.0

mcr.microsoft.com/dotnet/aspnet:8.0-alpine

Extra Info

Installing and testing other versions can be done by following definition
# RUN apk add --update --no-cache --repository=http://dl-cdn.alpinelinux.org/alpine/edge/testing/ libwasmtime  # Not working: V30
# ARG WASMTIME_VERSION=30.0.1
# ARG WASMTIME_VERSION=27.0.0
ARG WASMTIME_VERSION=26.0.1  # Last working version
RUN wget https://github.com/bytecodealliance/wasmtime/releases/download/v${WASMTIME_VERSION}/wasmtime-v${WASMTIME_VERSION}-x86_64-musl-c-api.tar.xz
RUN tar -xJvf wasmtime-v${WASMTIME_VERSION}-x86_64-musl-c-api.tar.xz -C /usr
RUN cp -r /usr/wasmtime-v${WASMTIME_VERSION}-x86_64-musl-c-api/include/. /usr/include
RUN cp -r /usr/wasmtime-v${WASMTIME_VERSION}-x86_64-musl-c-api/lib/. /usr/lib

Wasmtime GitHub notifications bot (Feb 24 2025 at 21:08):

alexcrichton commented on issue #10279:

Ok in that case I think that this is probably best to open on the wasmtime-dotnet repository. I don't think there's anything to do in this repository of Wasmtime itself, and wasmtime-dotnet has all the integration bindings I believe you're using.

I'm not familiar enough with wasmtime-dotnet to say what the best fix is myself, if you open an issue on wasmtime-dotnet I suspect folks over there will know better.

Last updated: Feb 28 2025 at 01:30 UTC