musl-c-api Version of Library Not Working Starting from Version 27.0.0 on Alpine Linux Distribution

[cernydav]

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. I’m using Opa.Wasm, which depends on wasmtime-dotnet.

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

• This is follow up of issue:
• • musl-c-api Version of Library Not Working Starting from Version 27.0.0 on Alpine Linux Distribution wasmtime#10279
• 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

[jsturtevant]

Thanks for the detailed report. I am not surprised it is not working, The last tested and updated version of wasm-time that was merged into this repository was wasmtime v22.

There have been some changes in the wasmtime C API and there hasn't been any changes to the bindings here. Keeping the api's update to date is a manual process (see for #329 for some ideas to automate). There was a change in maintainers and I sort of took over but haven't had a lot of time to focus on this project. Knowing there are some end users helps with priority.