wasmtime / issue #13733 C API `wasmtime_val_t` layout mis... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #13733 C API `wasmtime_val_t` layout mis...

Wasmtime GitHub notifications bot (Jun 25 2026 at 07:01):

crowforkotlin opened issue #13733:

Issue Description

On 32-bit platforms (e.g., i686-linux-android, armv7-linux-androideabi), the C API header wasmtime/val.h contains static_assert checks that require wasmtime_valunion_t and wasmtime_val_raw_t to be 8-byte aligned:
static_assert(__alignof(wasmtime_valunion_t) == 8, "should be 8-byte aligned");
static_assert(__alignof(wasmtime_val_raw_t) == 8, "should be 8-byte aligned");
However, on 32-bit platforms, int64_t and double only have 4-byte alignment in the C ABI, causing these assertions to fail at compile time.

Additionally, even if the assertions are bypassed, there is a layout mismatch between Rust and C on 32-bit platforms:

Rust #[repr(C)] C (original val.h)

union alignment 8 (Rust's i64/u64 are always 8-byte aligned) 4 (C ABI int64_t on 32-bit)

wasmtime_val_t.of offset 8 4

wasmtime_val_t size 32 20

This causes the C side to read garbage data for the kind field (e.g., unknown wasmtime_valkind_t: 16), leading to a SIGABRT crash at runtime when calling wasmtime_func_call.

Reproduction

Build libwasmtime.a for i686-linux-android (32-bit x86 Android)

Include wasmtime/val.h from C++ code compiled with the Android NDK (x86 target)

Compile fails with static_assert errors

If assertions are removed, runtime crash occurs: Abort message: 'unknown wasmtime_valkind_t: <garbage>'

Crash Log (x86 Android Emulator)
Abort message: 'unknown wasmtime_valkind_t: 16'
signal 6 (SIGABRT), code -1 (SI_QUEUE)
backtrace:
  #14 pc ... libwasmline.so (wasmtime_func_call+192)
  #15 pc ... libwasmline.so (wasmline::Session::invokeInbound+465)
  ...
Proposed Fix

Force 8-byte alignment on both C and Rust sides to ensure consistent layout across all platforms:

crates/c-api/include/wasmtime/val.h:
-typedef union wasmtime_valunion {
+typedef union alignas(8) wasmtime_valunion {

-typedef union wasmtime_val_raw {
+typedef union alignas(8) wasmtime_val_raw {

-typedef struct wasmtime_val {
+typedef struct alignas(8) wasmtime_val {
crates/c-api/src/val.rs:
-#[repr(C)]
+#[repr(C, align(8))]
 pub struct wasmtime_val_t {

-#[repr(C)]
+#[repr(C, align(8))]
 pub union wasmtime_val_union {
And update the compile-time assertion:
 const _: () = {
-    assert!(std::mem::size_of::<wasmtime_val_union>() <= 24);
-    assert!(std::mem::align_of::<wasmtime_val_union>() == std::mem::align_of::<u64>());
+    assert!(std::mem::size_of::<wasmtime_val_union>() <= 32);
+    assert!(std::mem::align_of::<wasmtime_val_union>() == 8);
 };
Impact

Platform Before Fix After Fix

x86_64 / aarch64 (64-bit) align=8, works :check: align=8, no change :check:

x86 / armv7a (32-bit) align=4, compile fails / runtime crash :cross_mark: align=8, works :check:

64-bit platforms: zero impact (alignas(8) is redundant, natural alignment is already 8)

32-bit platforms: fixes compile-time assertion failure and runtime layout mismatch

Memory overhead on 32-bit: ~12 bytes per wasmtime_val_t (negligible for typical usage)

API compatibility: no changes to type names or function signatures

Environment

Forked Wasmtime version: 45.0.6 (custom features pulley-min [x86/armv7a] )

Affected targets: i686-linux-android, armv7-linux-androideabi (and potentially other 32-bit targets)

Discovered while building wasmline (a Wasm plugin framework) with Pulley interpreter on 32-bit Android

Fix

https://github.com/crowforkotlin/wasmtime/commit/e24159c780779c7f36554c7578b94bd5b37708a0#diff-ed790182a50ae9da596d84eb7f31ac26eb4af8c326a9d19a637ab903c7a2091b

Result After Fix

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/e9c742d0-a673-4eae-b8eb-16e4ac49973e" />

	Rust `#[repr(C)]`	C (original `val.h`)
union alignment	8 (Rust's `i64`/`u64` are always 8-byte aligned)	4 (C ABI `int64_t` on 32-bit)
`wasmtime_val_t.of` offset	8	4
`wasmtime_val_t` size	32	20

Platform	Before Fix	After Fix
x86_64 / aarch64 (64-bit)	align=8, works :check:	align=8, no change :check:
x86 / armv7a (32-bit)	align=4, compile fails / runtime crash :cross_mark:	align=8, works :check:

Wasmtime GitHub notifications bot (Jun 25 2026 at 07:11):

bjorn3 commented on issue #13733:

Additionally, even if the assertions are bypassed, there is a layout mismatch between Rust and C on 32-bit platforms:

That may be a bug in rustc.

Wasmtime GitHub notifications bot (Jun 29 2026 at 13:42):

alexcrichton commented on issue #13733:

Can you share some more information about how to reproduce this? Local testing shows that the align of u64/f64 are both 8 on arm platforms. I know it can be 4 sometimes, but I'm not sure how you're seeing 4 on arm platforms.

One possible difference is that Rust uses u32/u64 for the f32/f64 wasm fields, but the C side uses float32_t and float64_t which means that if the align of u64 is not equal to f64 this'll cause problems. Before I fix that though I'd want to better understand how to reproduce and where the align 4 is coming from.

Wasmtime GitHub notifications bot (Jun 30 2026 at 04:17):

crowforkotlin commented on issue #13733:

Can you share some more information about how to reproduce this? Local testing shows that the align of u64/f64 are both 8 on arm platforms. I know it can be 4 sometimes, but I'm not sure how you're seeing 4 on arm platforms.您能再详细说明一下如何重现这一现象吗？本地测试结果显示，在 Arm 平台上，u64 和 f64 的对齐方式都是 8 位。我知道有时候对齐方式可能是 4 位，但不明白在 Arm 平台上为何会出现 4 位的对齐方式。

One possible difference is that Rust uses u32/u64 for the f32/f64 wasm fields, but the C side uses float32_t and float64_t which means that if the align of u64 is not equal to f64 this'll cause problems. Before I fix that though I'd want to better understand how to reproduce and where the align 4 is coming from.其中一个可能的区别是：Rust 在处理 f32/f64 类型的 WASM 字段时使用 u32 / u64 作为标识符，而 C 语言则使用 float32_t 和 float64_t 。这意味着，如果 u64 的对齐方式与 f64 不一致，就会引发问题。在解决这个问题之前，我需要先弄清楚如何重现该问题，以及 u64 的对齐方式究竟是如何确定的。

Replication Process and Issue Summary

The complete step-by-step replication procedure is available in the following repository:
https://github.com/crowforkotlin/wasmtime_c_api_32bit_issues

Overview of the Replication Flow

Once the alignment issue is successfully resolved, both compilation and execution pass without errors. The high-level replication process is structured as follows:

Artifact Generation: Build the linux-x86_64 CLI tools and the android-x86 C API components from the source code of the current repository fork.

Module Compilation: Use the compiled linux-x86_64 host toolchain to compile the kotlin.wasm file into a 32-bit Pulley WebAssembly module (kotlin.pwasm32).

Deployment: Push the generated kotlin.pwasm32 bytecode file to a 32-bit Android emulator.

Runner Compilation & Execution: Write a minimal C++ program that integrates with the Wasmtime C API, cross-compile it into an executable binary for the 32-bit Android platform, push it to the emulator, and execute the .pwasm32 module to observe the output.

Issue Context

While the runtime behavior functions correctly after patching, the primary defect occurs strictly during the compilation phase of the C++ runner application due to structural alignment mismatches enforced by the header file assertions.

Kotlin/Wasm --> kotlin.wasm
package crow.wasmline.sample

import kotlinx.serialization.ExperimentalSerializationApi

fun main() {    println("[Kotlin Wasi] Plugin main executed")}

@WasmExport(name="add")
fun add(numA: Int, numB: Int): Int { return numA + numB }

Wasmtime GitHub notifications bot (Jun 30 2026 at 08:21):

crowforkotlin edited a comment on issue #13733:

Can you share some more information about how to reproduce this? Local testing shows that the align of u64/f64 are both 8 on arm platforms. I know it can be 4 sometimes, but I'm not sure how you're seeing 4 on arm platforms.

One possible difference is that Rust uses u32/u64 for the f32/f64 wasm fields, but the C side uses float32_t and float64_t which means that if the align of u64 is not equal to f64 this'll cause problems. Before I fix that though I'd want to better understand how to reproduce and where the align 4 is coming from.

Replication Process and Issue Summary

The complete step-by-step replication procedure is available in the following repository:
https://github.com/crowforkotlin/wasmtime_c_api_32bit_issues

Overview of the Replication Flow

Once the alignment issue is successfully resolved, both compilation and execution pass without errors. The high-level replication process is structured as follows:

Artifact Generation: Build the linux-x86_64 CLI tools and the android-x86 C API components from the source code of the current repository fork.

Module Compilation: Use the compiled linux-x86_64 host toolchain to compile the kotlin.wasm file into a 32-bit Pulley WebAssembly module (kotlin.pwasm32).

Deployment: Push the generated kotlin.pwasm32 bytecode file to a 32-bit Android emulator.

Runner Compilation & Execution: Write a minimal C++ program that integrates with the Wasmtime C API, cross-compile it into an executable binary for the 32-bit Android platform, push it to the emulator, and execute the .pwasm32 module to observe the output.

Issue Context

While the runtime behavior functions correctly after patching, the primary defect occurs strictly during the compilation phase of the C++ runner application due to structural alignment mismatches enforced by the header file assertions.

Kotlin/Wasm --> kotlin.wasm
package crow.wasmline.sample

import kotlinx.serialization.ExperimentalSerializationApi

fun main() {    println("[Kotlin Wasi] Plugin main executed")}

@WasmExport(name="add")
fun add(numA: Int, numB: Int): Int { return numA + numB }

Wasmtime GitHub notifications bot (Jun 30 2026 at 08:27):

crowforkotlin commented on issue #13733:

Can you share some more information about how to reproduce this? Local testing shows that the align of u64/f64 are both 8 on arm platforms. I know it can be 4 sometimes, but I'm not sure how you're seeing 4 on arm platforms.

One possible difference is that Rust uses u32/u64 for the f32/f64 wasm fields, but the C side uses float32_t and float64_t which means that if the align of u64 is not equal to f64 this'll cause problems. Before I fix that though I'd want to better understand how to reproduce and where the align 4 is coming from.

In file included from /home/crowf/Downloads/error-result/pulley-runner.cpp:12:
In file included from /home/crowf/Downloads/error-result/wasmtime-dev-x86-android-c-api/include/wasmtime.h:199:
In file included from /home/crowf/Downloads/error-result/wasmtime-dev-x86-android-c-api/include/wasmtime/anyref.h:12:
/home/crowf/Downloads/error-result/wasmtime-dev-x86-android-c-api/include/wasmtime/val.h:353:17: error: static assertion failed due to requirement '__alignof(wasmtime_valunion) == 8': should be 8-byte aligned
  353 |   static_assert(__alignof(wasmtime_valunion_t) == 8,
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/crowf/Downloads/error-result/wasmtime-dev-x86-android-c-api/include/wasmtime/val.h:353:48: note: expression evaluates to '4 == 8'
  353 |   static_assert(__alignof(wasmtime_valunion_t) == 8,
      |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
/home/crowf/Downloads/error-result/wasmtime-dev-x86-android-c-api/include/wasmtime/val.h:356:17: error: static assertion failed due to requirement '__alignof(wasmtime_val_raw) == 8': should be 8-byte aligned
  356 |   static_assert(__alignof(wasmtime_val_raw_t) == 8, "should be 8-byte aligned");
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/crowf/Downloads/error-result/wasmtime-dev-x86-android-c-api/include/wasmtime/val.h:356:47: note: expression evaluates to '4 == 8'
  356 |   static_assert(__alignof(wasmtime_val_raw_t) == 8, "should be 8-byte aligned");
      |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~

Wasmtime GitHub notifications bot (Jun 30 2026 at 17:44):

alexcrichton commented on issue #13733:

I want to be sure you're aware of our ai tool usage policy, but can this be reduced a bit more perhaps? It looks like while armv7 has alignment 8 the i686 platform has alignment 4. I'm still specifically curious about:

Crash Log (x86 Android Emulator)

you pasted above where if you removed the assertions crashes still happened. The alignment checks should be fixed in https://github.com/bytecodealliance/wasmtime/pull/13753, but if there's still a crash remaining that's worth investigating. Can you create a standalone C reproducer or something similar?

Wasmtime GitHub notifications bot (Jun 30 2026 at 17:57):

crowforkotlin commented on issue #13733:

I want to be sure you're aware of our ai tool usage policy, but can this be reduced a bit more perhaps? It looks like while armv7 has alignment 8 the i686 platform has alignment 4. I'm still specifically curious about:

Crash Log (x86 Android Emulator)

you pasted above where if you removed the assertions crashes still happened. The alignment checks should be fixed in #13753, but if there's still a crash remaining that's worth investigating. Can you create a standalone C reproducer or something similar?

I've already fixed the runtime crash in my fork. It was my oversight—it came from an earlier AI diagnosis, and I forgot to clean it up. Sorry about that (I'll check out the AI Tool Use Policy to avoid any more issues).

Now, only the compile-time errors are left. I tested it this morning and found that the assertions definitely need some tweaks. Also, val.rs and val.h must be set to #[repr(C, align(8))] to pass compilation. Just to be safe, I’ve opened an issue for this, as I'm not entirely sure if these changes will cause other problems.

As for armv7a, I don't have a device to test it on right now, but I can try running a v7a build on a v8a phone tomorrow to see if I can reproduce it. (By the way, it reproduces 100% on 32-bit x86—I spent this morning working on that part for the issue).

Lastly, about the minimal C reproduction: honestly, it’s a bit of a hassle. Even with AI help, setting up a minimal C++ sample today was super complicated due to the workflow. I'm not sure how you guys usually handle this, but rewriting it into pure C will probably take me quite some time. I'll give it a shot when I have some free time.

Wasmtime GitHub notifications bot (Jun 30 2026 at 17:59):

crowforkotlin commented on issue #13733:

I'll port the fix commit https://github.com/bytecodealliance/wasmtime/pull/13753 to my code tomorrow to check if the compile error persists. If there are any runtime issues, I'll give feedback in time.

#13753

Wasmtime GitHub notifications bot (Jun 30 2026 at 18:31):

alexcrichton commented on issue #13733:

To clarify, align(8) shouldn't be necessary and it's not desired. The previous assertions were just buggy and needed fixing, the code didn't need other changes.

For reproduction, yeah I understand that minimization isn't always easy. That being said there's a chasm of the understanding of wasmtime maintainers and what you're working on, and somehow that chasm needs to be bridged. On one hand you can cross the chasm by creating a minimal reproduction, but on the other hand we could put in a lot of time to learn what you're doing and cross the chasm as well. Who's got the time depends on a whole bunch of factors, but I want to point out primarily that it's quite a lot of work to ask and/or expect of wasmtime maintainers to fully internalize such a large project (and I subjectively thought it had quite a lot of AI noise too)

Wasmtime GitHub notifications bot (Jul 01 2026 at 03:04):

crowforkotlin commented on issue #13733:

To clarify, align(8) shouldn't be necessary and it's not desired. The previous assertions were just buggy and needed fixing, the code didn't need other changes.

For reproduction, yeah I understand that minimization isn't always easy. That being said there's a chasm of the understanding of wasmtime maintainers and what you're working on, and somehow that chasm needs to be bridged. On one hand you can cross the chasm by creating a minimal reproduction, but on the other hand we could put in a lot of time to learn what you're doing and cross the chasm as well. Who's got the time depends on a whole bunch of factors, but I want to point out primarily that it's quite a lot of work to ask and/or expect of wasmtime maintainers to fully internalize such a large project (and I subjectively thought it had quite a lot of AI noise too)

That makes sense, thanks for the explanation. Just verified the fix locally on x86 — everything looks good now. Thanks!

Wasmtime GitHub notifications bot (Jul 01 2026 at 03:04):

crowforkotlin closed issue #13733:

Issue Description

On 32-bit platforms (e.g., i686-linux-android, armv7-linux-androideabi), the C API header wasmtime/val.h contains static_assert checks that require wasmtime_valunion_t and wasmtime_val_raw_t to be 8-byte aligned:
static_assert(__alignof(wasmtime_valunion_t) == 8, "should be 8-byte aligned");
static_assert(__alignof(wasmtime_val_raw_t) == 8, "should be 8-byte aligned");
However, on 32-bit platforms, int64_t and double only have 4-byte alignment in the C ABI, causing these assertions to fail at compile time.

Additionally, even if the assertions are bypassed, there is a layout mismatch between Rust and C on 32-bit platforms:

Rust #[repr(C)] C (original val.h)

union alignment 8 (Rust's i64/u64 are always 8-byte aligned) 4 (C ABI int64_t on 32-bit)

wasmtime_val_t.of offset 8 4

wasmtime_val_t size 32 20

This causes the C side to read garbage data for the kind field (e.g., unknown wasmtime_valkind_t: 16), leading to a SIGABRT crash at runtime when calling wasmtime_func_call.

Reproduction

Build libwasmtime.a for i686-linux-android (32-bit x86 Android)

Include wasmtime/val.h from C++ code compiled with the Android NDK (x86 target)

Compile fails with static_assert errors

If assertions are removed, runtime crash occurs: Abort message: 'unknown wasmtime_valkind_t: <garbage>'

Crash Log (x86 Android Emulator)
Abort message: 'unknown wasmtime_valkind_t: 16'
signal 6 (SIGABRT), code -1 (SI_QUEUE)
backtrace:
  #14 pc ... libwasmline.so (wasmtime_func_call+192)
  #15 pc ... libwasmline.so (wasmline::Session::invokeInbound+465)
  ...
Proposed Fix

Force 8-byte alignment on both C and Rust sides to ensure consistent layout across all platforms:

crates/c-api/include/wasmtime/val.h:
-typedef union wasmtime_valunion {
+typedef union alignas(8) wasmtime_valunion {

-typedef union wasmtime_val_raw {
+typedef union alignas(8) wasmtime_val_raw {

-typedef struct wasmtime_val {
+typedef struct alignas(8) wasmtime_val {
crates/c-api/src/val.rs:
-#[repr(C)]
+#[repr(C, align(8))]
 pub struct wasmtime_val_t {

-#[repr(C)]
+#[repr(C, align(8))]
 pub union wasmtime_val_union {
And update the compile-time assertion:
 const _: () = {
-    assert!(std::mem::size_of::<wasmtime_val_union>() <= 24);
-    assert!(std::mem::align_of::<wasmtime_val_union>() == std::mem::align_of::<u64>());
+    assert!(std::mem::size_of::<wasmtime_val_union>() <= 32);
+    assert!(std::mem::align_of::<wasmtime_val_union>() == 8);
 };
Impact

Platform Before Fix After Fix

x86_64 / aarch64 (64-bit) align=8, works :check: align=8, no change :check:

x86 / armv7a (32-bit) align=4, compile fails / runtime crash :cross_mark: align=8, works :check:

64-bit platforms: zero impact (alignas(8) is redundant, natural alignment is already 8)

32-bit platforms: fixes compile-time assertion failure and runtime layout mismatch

Memory overhead on 32-bit: ~12 bytes per wasmtime_val_t (negligible for typical usage)

API compatibility: no changes to type names or function signatures

Environment

Forked Wasmtime version: 45.0.6 (custom features pulley-min [x86/armv7a] )

Affected targets: i686-linux-android, armv7-linux-androideabi (and potentially other 32-bit targets)

Discovered while building wasmline (a Wasm plugin framework) with Pulley interpreter on 32-bit Android

Fix

https://github.com/crowforkotlin/wasmtime/commit/e24159c780779c7f36554c7578b94bd5b37708a0#diff-ed790182a50ae9da596d84eb7f31ac26eb4af8c326a9d19a637ab903c7a2091b

Result After Fix

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/e9c742d0-a673-4eae-b8eb-16e4ac49973e" />

	Rust `#[repr(C)]`	C (original `val.h`)
union alignment	8 (Rust's `i64`/`u64` are always 8-byte aligned)	4 (C ABI `int64_t` on 32-bit)
`wasmtime_val_t.of` offset	8	4
`wasmtime_val_t` size	32	20

Platform	Before Fix	After Fix
x86_64 / aarch64 (64-bit)	align=8, works :check:	align=8, no change :check:
x86 / armv7a (32-bit)	align=4, compile fails / runtime crash :cross_mark:	align=8, works :check:

Wasmtime GitHub notifications bot (Jul 01 2026 at 03:48):

crowforkotlin reopened issue #13733:

Issue Description

On 32-bit platforms (e.g., i686-linux-android, armv7-linux-androideabi), the C API header wasmtime/val.h contains static_assert checks that require wasmtime_valunion_t and wasmtime_val_raw_t to be 8-byte aligned:
static_assert(__alignof(wasmtime_valunion_t) == 8, "should be 8-byte aligned");
static_assert(__alignof(wasmtime_val_raw_t) == 8, "should be 8-byte aligned");
However, on 32-bit platforms, int64_t and double only have 4-byte alignment in the C ABI, causing these assertions to fail at compile time.

Additionally, even if the assertions are bypassed, there is a layout mismatch between Rust and C on 32-bit platforms:

Rust #[repr(C)] C (original val.h)

union alignment 8 (Rust's i64/u64 are always 8-byte aligned) 4 (C ABI int64_t on 32-bit)

wasmtime_val_t.of offset 8 4

wasmtime_val_t size 32 20

This causes the C side to read garbage data for the kind field (e.g., unknown wasmtime_valkind_t: 16), leading to a SIGABRT crash at runtime when calling wasmtime_func_call.

Reproduction

Build libwasmtime.a for i686-linux-android (32-bit x86 Android)

Include wasmtime/val.h from C++ code compiled with the Android NDK (x86 target)

Compile fails with static_assert errors

If assertions are removed, runtime crash occurs: Abort message: 'unknown wasmtime_valkind_t: <garbage>'

Crash Log (x86 Android Emulator)
Abort message: 'unknown wasmtime_valkind_t: 16'
signal 6 (SIGABRT), code -1 (SI_QUEUE)
backtrace:
  #14 pc ... libwasmline.so (wasmtime_func_call+192)
  #15 pc ... libwasmline.so (wasmline::Session::invokeInbound+465)
  ...
Proposed Fix

Force 8-byte alignment on both C and Rust sides to ensure consistent layout across all platforms:

crates/c-api/include/wasmtime/val.h:
-typedef union wasmtime_valunion {
+typedef union alignas(8) wasmtime_valunion {

-typedef union wasmtime_val_raw {
+typedef union alignas(8) wasmtime_val_raw {

-typedef struct wasmtime_val {
+typedef struct alignas(8) wasmtime_val {
crates/c-api/src/val.rs:
-#[repr(C)]
+#[repr(C, align(8))]
 pub struct wasmtime_val_t {

-#[repr(C)]
+#[repr(C, align(8))]
 pub union wasmtime_val_union {
And update the compile-time assertion:
 const _: () = {
-    assert!(std::mem::size_of::<wasmtime_val_union>() <= 24);
-    assert!(std::mem::align_of::<wasmtime_val_union>() == std::mem::align_of::<u64>());
+    assert!(std::mem::size_of::<wasmtime_val_union>() <= 32);
+    assert!(std::mem::align_of::<wasmtime_val_union>() == 8);
 };
Impact

Platform Before Fix After Fix

x86_64 / aarch64 (64-bit) align=8, works :check: align=8, no change :check:

x86 / armv7a (32-bit) align=4, compile fails / runtime crash :cross_mark: align=8, works :check:

64-bit platforms: zero impact (alignas(8) is redundant, natural alignment is already 8)

32-bit platforms: fixes compile-time assertion failure and runtime layout mismatch

Memory overhead on 32-bit: ~12 bytes per wasmtime_val_t (negligible for typical usage)

API compatibility: no changes to type names or function signatures

Environment

Forked Wasmtime version: 45.0.6 (custom features pulley-min [x86/armv7a] )

Affected targets: i686-linux-android, armv7-linux-androideabi (and potentially other 32-bit targets)

Discovered while building wasmline (a Wasm plugin framework) with Pulley interpreter on 32-bit Android

Fix

https://github.com/crowforkotlin/wasmtime/commit/e24159c780779c7f36554c7578b94bd5b37708a0#diff-ed790182a50ae9da596d84eb7f31ac26eb4af8c326a9d19a637ab903c7a2091b

Result After Fix

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/e9c742d0-a673-4eae-b8eb-16e4ac49973e" />

	Rust `#[repr(C)]`	C (original `val.h`)
union alignment	8 (Rust's `i64`/`u64` are always 8-byte aligned)	4 (C ABI `int64_t` on 32-bit)
`wasmtime_val_t.of` offset	8	4
`wasmtime_val_t` size	32	20

Platform	Before Fix	After Fix
x86_64 / aarch64 (64-bit)	align=8, works :check:	align=8, no change :check:
x86 / armv7a (32-bit)	align=4, compile fails / runtime crash :cross_mark:	align=8, works :check:

Wasmtime GitHub notifications bot (Jul 01 2026 at 04:02):

crowforkotlin edited a comment on issue #13733:

To clarify, align(8) shouldn't be necessary and it's not desired. The previous assertions were just buggy and needed fixing, the code didn't need other changes.

For reproduction, yeah I understand that minimization isn't always easy. That being said there's a chasm of the understanding of wasmtime maintainers and what you're working on, and somehow that chasm needs to be bridged. On one hand you can cross the chasm by creating a minimal reproduction, but on the other hand we could put in a lot of time to learn what you're doing and cross the chasm as well. Who's got the time depends on a whole bunch of factors, but I want to point out primarily that it's quite a lot of work to ask and/or expect of wasmtime maintainers to fully internalize such a large project (and I subjectively thought it had quite a lot of AI noise too)

That makes sense, thanks for the explanation.

To give an update, I’ve ported the fixed code back into my local codebase. While the Rust side now compiles successfully, I hit a static assertion failure during the subsequent NDK build stage. The C++ compiler complains that wasmtime_valunion_t and wasmtime_val_raw_t are evaluated to 4-byte alignment instead of the expected 8 bytes:
error: static assertion failed due to requirement '__alignof(wasmtime_valunion) == 8': should be 8-byte aligned
note: expression evaluates to '4 == 8'
To investigate whether this is an inherent alignment difference on 32-bit x86, I wrote a minimal C program and tested it on an i686-linux-android target. The output confirmed that uint64_t and double (and consequently the union) are indeed 4-byte aligned on this platform.

Here is the test code and its execution output:
// test_align.c — compile target: i686-linux-android
#include <stdio.h>
#include <stdint.h>
#include <stddef.h>

typedef union {
    int32_t  i32;
    int64_t  i64;
    float    f32;
    double   f64;
    void    *ptr;
} test_union_t;

int main() {
    printf("sizeof(uint64_t)  = %zu\n", sizeof(uint64_t));
    printf("alignof(uint64_t) = %zu\n", _Alignof(uint64_t));
    printf("sizeof(double)    = %zu\n", sizeof(double));
    printf("alignof(double)   = %zu\n", _Alignof(double));
    printf("sizeof(void*)     = %zu\n", sizeof(void*));
    printf("alignof(void*)    = %zu\n", _Alignof(void*));
    printf("sizeof(test_union_t)  = %zu\n", sizeof(test_union_t));
    printf("alignof(test_union_t) = %zu\n", _Alignof(test_union_t));
    return 0;
}
Output on device via adb:
sizeof(uint64_t)  = 8
alignof(uint64_t) = 4
sizeof(double)    = 8
alignof(double)   = 4
sizeof(void*)     = 4
alignof(void*)    = 4
sizeof(test_union_t)  = 8
alignof(test_union_t) = 4
<img width="665" height="631" alt="Image" src="https://github.com/user-attachments/assets/61bf7d9c-0378-4a0e-a2e8-bf15f8ab7354" />

Given this, on 32-bit x86 Android, the natural alignment for these 64-bit types is 4. This seems to be why the static_assert(..., 8) fails during the NDK build unless we explicitly enforce alignment attributes in the headers. How should we best reconcile this ABI discrepancy between Rust and C on 32-bit platforms?

Wasmtime GitHub notifications bot (Jul 01 2026 at 04:03):

crowforkotlin edited a comment on issue #13733:

To clarify, align(8) shouldn't be necessary and it's not desired. The previous assertions were just buggy and needed fixing, the code didn't need other changes.

For reproduction, yeah I understand that minimization isn't always easy. That being said there's a chasm of the understanding of wasmtime maintainers and what you're working on, and somehow that chasm needs to be bridged. On one hand you can cross the chasm by creating a minimal reproduction, but on the other hand we could put in a lot of time to learn what you're doing and cross the chasm as well. Who's got the time depends on a whole bunch of factors, but I want to point out primarily that it's quite a lot of work to ask and/or expect of wasmtime maintainers to fully internalize such a large project (and I subjectively thought it had quite a lot of AI noise too)

That makes sense, thanks for the explanation.

To give an update, I’ve ported the fixed code back into my local codebase. While the Rust side now compiles successfully, I hit a static assertion failure during the subsequent NDK build stage. compiler complains that wasmtime_valunion_t and wasmtime_val_raw_t are evaluated to 4-byte alignment instead of the expected 8 bytes:
error: static assertion failed due to requirement '__alignof(wasmtime_valunion) == 8': should be 8-byte aligned
note: expression evaluates to '4 == 8'
To investigate whether this is an inherent alignment difference on 32-bit x86, I wrote a minimal C program and tested it on an i686-linux-android target. The output confirmed that uint64_t and double (and consequently the union) are indeed 4-byte aligned on this platform.

Here is the test code and its execution output:
// test_align.c — compile target: i686-linux-android
#include <stdio.h>
#include <stdint.h>
#include <stddef.h>

typedef union {
    int32_t  i32;
    int64_t  i64;
    float    f32;
    double   f64;
    void    *ptr;
} test_union_t;

int main() {
    printf("sizeof(uint64_t)  = %zu\n", sizeof(uint64_t));
    printf("alignof(uint64_t) = %zu\n", _Alignof(uint64_t));
    printf("sizeof(double)    = %zu\n", sizeof(double));
    printf("alignof(double)   = %zu\n", _Alignof(double));
    printf("sizeof(void*)     = %zu\n", sizeof(void*));
    printf("alignof(void*)    = %zu\n", _Alignof(void*));
    printf("sizeof(test_union_t)  = %zu\n", sizeof(test_union_t));
    printf("alignof(test_union_t) = %zu\n", _Alignof(test_union_t));
    return 0;
}
Output on device via adb:
sizeof(uint64_t)  = 8
alignof(uint64_t) = 4
sizeof(double)    = 8
alignof(double)   = 4
sizeof(void*)     = 4
alignof(void*)    = 4
sizeof(test_union_t)  = 8
alignof(test_union_t) = 4
<img width="665" height="631" alt="Image" src="https://github.com/user-attachments/assets/61bf7d9c-0378-4a0e-a2e8-bf15f8ab7354" />

Given this, on 32-bit x86 Android, the natural alignment for these 64-bit types is 4. This seems to be why the static_assert(..., 8) fails during the NDK build unless we explicitly enforce alignment attributes in the headers. How should we best reconcile this ABI discrepancy between Rust and C on 32-bit platforms?

Wasmtime GitHub notifications bot (Jul 01 2026 at 05:55):

crowforkotlin edited a comment on issue #13733:

To clarify, align(8) shouldn't be necessary and it's not desired. The previous assertions were just buggy and needed fixing, the code didn't need other changes.

For reproduction, yeah I understand that minimization isn't always easy. That being said there's a chasm of the understanding of wasmtime maintainers and what you're working on, and somehow that chasm needs to be bridged. On one hand you can cross the chasm by creating a minimal reproduction, but on the other hand we could put in a lot of time to learn what you're doing and cross the chasm as well. Who's got the time depends on a whole bunch of factors, but I want to point out primarily that it's quite a lot of work to ask and/or expect of wasmtime maintainers to fully internalize such a large project (and I subjectively thought it had quite a lot of AI noise too)

That makes sense, thanks for the explanation.

To give an update, I’ve ported the fixed code back into my local codebase. While the Rust side now compiles successfully, I hit a static assertion failure during the subsequent NDK build stage. compiler complains that wasmtime_valunion_t and wasmtime_val_raw_t are evaluated to 4-byte alignment instead of the expected 8 bytes:
error: static assertion failed due to requirement '__alignof(wasmtime_valunion) == 8': should be 8-byte aligned
note: expression evaluates to '4 == 8'
To investigate whether this is an inherent alignment difference on 32-bit x86, I wrote a minimal C program and tested it on an i686-linux-android target. The output confirmed that uint64_t and double (and consequently the union) are indeed 4-byte aligned on this platform.

Here is the test code and its execution output:
// test_align.c — compiler target: i686-linux-android
#include <stdalign.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

typedef union {
  int32_t i32;
  int64_t i64;
  float f32;
  double f64;
  void *ptr;
} test_union_t;

int main() {
  printf("sizeof(uint64_t)  = %zu\n", sizeof(uint64_t));
  printf("alignof(uint64_t) = %zu\n", alignof(uint64_t));
  printf("sizeof(double)    = %zu\n", sizeof(double));
  printf("alignof(double)   = %zu\n", alignof(double));
  printf("sizeof(void*)     = %zu\n", sizeof(void *));
  printf("alignof(void*)    = %zu\n", alignof(void *));
  printf("sizeof(test_union_t)  = %zu\n", sizeof(test_union_t));
  printf("alignof(test_union_t) = %zu\n", alignof(test_union_t));
  return 0;
}
Output on device via adb:
sizeof(uint64_t)  = 8
alignof(uint64_t) = 4
sizeof(double)    = 8
alignof(double)   = 4
sizeof(void*)     = 4
alignof(void*)    = 4
sizeof(test_union_t)  = 8
alignof(test_union_t) = 4
<img width="1040" height="790" alt="Image" src="https://github.com/user-attachments/assets/b9177ec5-89a4-483a-b099-3e9d1b5f3c92" />

Given this, on 32-bit x86 Android, the natural alignment for these 64-bit types is 4. This seems to be why the static_assert(..., 8) fails during the NDK build unless we explicitly enforce alignment attributes in the headers. How should we best reconcile this ABI discrepancy between Rust and C on 32-bit platforms?

Wasmtime GitHub notifications bot (Jul 01 2026 at 06:08):

crowforkotlin edited a comment on issue #13733:

To clarify, align(8) shouldn't be necessary and it's not desired. The previous assertions were just buggy and needed fixing, the code didn't need other changes.

For reproduction, yeah I understand that minimization isn't always easy. That being said there's a chasm of the understanding of wasmtime maintainers and what you're working on, and somehow that chasm needs to be bridged. On one hand you can cross the chasm by creating a minimal reproduction, but on the other hand we could put in a lot of time to learn what you're doing and cross the chasm as well. Who's got the time depends on a whole bunch of factors, but I want to point out primarily that it's quite a lot of work to ask and/or expect of wasmtime maintainers to fully internalize such a large project (and I subjectively thought it had quite a lot of AI noise too)

That makes sense, thanks for the explanation.

To give an update, I’ve ported the fixed code back into my local codebase. While the Rust side now compiles successfully, I hit a static assertion failure during the subsequent NDK build stage. compiler complains that wasmtime_valunion_t and wasmtime_val_raw_t are evaluated to 4-byte alignment instead of the expected 8 bytes:
error: static assertion failed due to requirement '__alignof(wasmtime_valunion) == 8': should be 8-byte aligned
note: expression evaluates to '4 == 8'
To investigate whether this is an inherent alignment difference on 32-bit x86, I wrote a minimal C program and tested it on an i686-linux-android target. The output confirmed that uint64_t and double (and consequently the union) are indeed 4-byte aligned on this platform.

Here is the test code and its execution output:
// test_align.c — compiler target: i686-linux-android
#include <stdalign.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

typedef union {
  int32_t i32;
  int64_t i64;
  float f32;
  double f64;
  void *ptr;
} test_union_t;

int main() {
  printf("sizeof(uint64_t)  = %zu\n", sizeof(uint64_t));
  printf("alignof(uint64_t) = %zu\n", alignof(uint64_t));
  printf("sizeof(double)    = %zu\n", sizeof(double));
  printf("alignof(double)   = %zu\n", alignof(double));
  printf("sizeof(void*)     = %zu\n", sizeof(void *));
  printf("alignof(void*)    = %zu\n", alignof(void *));
  printf("sizeof(test_union_t)  = %zu\n", sizeof(test_union_t));
  printf("alignof(test_union_t) = %zu\n", alignof(test_union_t));
  return 0;
}
Output on device via adb:
sizeof(uint64_t)  = 8
alignof(uint64_t) = 4
sizeof(double)    = 8
alignof(double)   = 4
sizeof(void*)     = 4
alignof(void*)    = 4
sizeof(test_union_t)  = 8
alignof(test_union_t) = 4
<img width="1040" height="790" alt="Image" src="https://github.com/user-attachments/assets/b9177ec5-89a4-483a-b099-3e9d1b5f3c92" />
$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/clang \
    --target=i686-linux-android23 \
    test_align.c -o test_align
adb push test_align /data/local/tmp/
adb shell chmod +x /data/local/tmp/test_align
adb shell /data/local/tmp/test_align
Given this, on 32-bit x86 Android, the natural alignment for these 64-bit types is 4. This seems to be why the static_assert(..., 8) fails during the NDK build unless we explicitly enforce alignment attributes in the headers. How should we best reconcile this ABI discrepancy between Rust and C on 32-bit platforms?

Wasmtime GitHub notifications bot (Jul 01 2026 at 06:09):

crowforkotlin edited a comment on issue #13733:

To clarify, align(8) shouldn't be necessary and it's not desired. The previous assertions were just buggy and needed fixing, the code didn't need other changes.

For reproduction, yeah I understand that minimization isn't always easy. That being said there's a chasm of the understanding of wasmtime maintainers and what you're working on, and somehow that chasm needs to be bridged. On one hand you can cross the chasm by creating a minimal reproduction, but on the other hand we could put in a lot of time to learn what you're doing and cross the chasm as well. Who's got the time depends on a whole bunch of factors, but I want to point out primarily that it's quite a lot of work to ask and/or expect of wasmtime maintainers to fully internalize such a large project (and I subjectively thought it had quite a lot of AI noise too)

That makes sense, thanks for the explanation.

To give an update, I’ve ported the fixed code back into my local codebase. While the Rust side now compiles successfully, I hit a static assertion failure during the subsequent NDK build stage. compiler complains that wasmtime_valunion_t and wasmtime_val_raw_t are evaluated to 4-byte alignment instead of the expected 8 bytes:
error: static assertion failed due to requirement '__alignof(wasmtime_valunion) == 8': should be 8-byte aligned
note: expression evaluates to '4 == 8'
To investigate whether this is an inherent alignment difference on 32-bit x86, I wrote a minimal C program and tested it on an i686-linux-android target. The output confirmed that uint64_t and double (and consequently the union) are indeed 4-byte aligned on this platform.

Here is the test code and its execution output:
// test_align.c — compiler target: i686-linux-android
#include <stdalign.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

typedef union {
  int32_t i32;
  int64_t i64;
  float f32;
  double f64;
  void *ptr;
} test_union_t;

int main() {
  printf("sizeof(uint64_t)  = %zu\n", sizeof(uint64_t));
  printf("alignof(uint64_t) = %zu\n", alignof(uint64_t));
  printf("sizeof(double)    = %zu\n", sizeof(double));
  printf("alignof(double)   = %zu\n", alignof(double));
  printf("sizeof(void*)     = %zu\n", sizeof(void *));
  printf("alignof(void*)    = %zu\n", alignof(void *));
  printf("sizeof(test_union_t)  = %zu\n", sizeof(test_union_t));
  printf("alignof(test_union_t) = %zu\n", alignof(test_union_t));
  return 0;
}
Output on device via adb:
sizeof(uint64_t)  = 8
alignof(uint64_t) = 4
sizeof(double)    = 8
alignof(double)   = 4
sizeof(void*)     = 4
alignof(void*)    = 4
sizeof(test_union_t)  = 8
alignof(test_union_t) = 4
<img width="1040" height="790" alt="Image" src="https://github.com/user-attachments/assets/b9177ec5-89a4-483a-b099-3e9d1b5f3c92" />
$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/clang \
    --target=i686-linux-android23 \
    test_align.c -o test_align
adb push test_align /data/local/tmp/
adb shell chmod +x /data/local/tmp/test_align
adb shell /data/local/tmp/test_align
Given this, on 32-bit x86 Android, the natural alignment for these 64-bit types is 4. This seems to be why the static_assert(..., 8) fails during the NDK build unless we explicitly enforce alignment attributes in the headers. How should we best reconcile this ABI discrepancy between Rust and C on 32-bit platforms?

Wasmtime GitHub notifications bot (Jul 01 2026 at 06:16):

crowforkotlin edited a comment on issue #13733:

To clarify, align(8) shouldn't be necessary and it's not desired. The previous assertions were just buggy and needed fixing, the code didn't need other changes.

For reproduction, yeah I understand that minimization isn't always easy. That being said there's a chasm of the understanding of wasmtime maintainers and what you're working on, and somehow that chasm needs to be bridged. On one hand you can cross the chasm by creating a minimal reproduction, but on the other hand we could put in a lot of time to learn what you're doing and cross the chasm as well. Who's got the time depends on a whole bunch of factors, but I want to point out primarily that it's quite a lot of work to ask and/or expect of wasmtime maintainers to fully internalize such a large project (and I subjectively thought it had quite a lot of AI noise too)

That makes sense, thanks for the explanation.

To give an update, I’ve ported the fixed code back into my local codebase. While the Rust side now compiles successfully, I hit a static assertion failure during the subsequent NDK build stage. compiler complains that wasmtime_valunion_t and wasmtime_val_raw_t are evaluated to 4-byte alignment instead of the expected 8 bytes:
error: static assertion failed due to requirement '__alignof(wasmtime_valunion) == 8': should be 8-byte aligned
note: expression evaluates to '4 == 8'
To investigate whether this is an inherent alignment difference on 32-bit x86, I wrote a minimal C program and tested it on an i686-linux-android target. The output confirmed that uint64_t and double (and consequently the union) are indeed 4-byte aligned on this platform.

Here is the test code and its execution output:
// test_align.c — compiler target: i686-linux-android
#include <stdalign.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

typedef union {
  int32_t i32;
  int64_t i64;
  float f32;
  double f64;
  void *ptr;
} test_union_t;

int main() {
  printf("sizeof(uint64_t)  = %zu\n", sizeof(uint64_t));
  printf("alignof(uint64_t) = %zu\n", alignof(uint64_t));
  printf("sizeof(double)    = %zu\n", sizeof(double));
  printf("alignof(double)   = %zu\n", alignof(double));
  printf("sizeof(void*)     = %zu\n", sizeof(void *));
  printf("alignof(void*)    = %zu\n", alignof(void *));
  printf("sizeof(test_union_t)  = %zu\n", sizeof(test_union_t));
  printf("alignof(test_union_t) = %zu\n", alignof(test_union_t));
  return 0;
}
Output on device via adb:
sizeof(uint64_t)  = 8
alignof(uint64_t) = 4
sizeof(double)    = 8
alignof(double)   = 4
sizeof(void*)     = 4
alignof(void*)    = 4
sizeof(test_union_t)  = 8
alignof(test_union_t) = 4
<img width="1040" height="790" alt="Image" src="https://github.com/user-attachments/assets/b9177ec5-89a4-483a-b099-3e9d1b5f3c92" />
$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/clang \
    --target=i686-linux-android23 \
    test_align.c -o test_align
adb push test_align /data/local/tmp/
adb shell chmod +x /data/local/tmp/test_align
adb shell /data/local/tmp/test_align
$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/clang \
    --target=armv7-linux-androideabi23 \
    -c test_align_v2.c -o test_align_v2.o
test_align_v2.c:12:16: error: static assertion failed due to requirement '__alignof(test_union_t) == 4': Error: test_union_t is NOT 8-byte aligned!
   12 | _Static_assert(__alignof(test_union_t) == 4,
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
test_align_v2.c:12:40: note: expression evaluates to '8 == 4'
   12 | _Static_assert(__alignof(test_union_t) == 4,
      |                ~~~~~~~~~~~~~~~~~~~~~~~~^~~~
1 error generated.
---
#include <stddef.h>
#include <stdint.h>

typedef union {
  int32_t i32;
  int64_t i64;
  float f32;
  double f64;
  void *ptr;
} test_union_t;

_Static_assert(__alignof(test_union_t) == 4, "error: test_union_t is NOT 8-byte aligned!");

int main() { return 0; }
Given this, on 32-bit x86 Android, the natural alignment for these 64-bit types is 4. This seems to be why the static_assert(..., 8) fails during the NDK build unless we explicitly enforce alignment attributes in the headers. How should we best reconcile this ABI discrepancy between Rust and C on 32-bit platforms?

Wasmtime GitHub notifications bot (Jul 01 2026 at 06:17):

crowforkotlin edited a comment on issue #13733:

To clarify, align(8) shouldn't be necessary and it's not desired. The previous assertions were just buggy and needed fixing, the code didn't need other changes.

For reproduction, yeah I understand that minimization isn't always easy. That being said there's a chasm of the understanding of wasmtime maintainers and what you're working on, and somehow that chasm needs to be bridged. On one hand you can cross the chasm by creating a minimal reproduction, but on the other hand we could put in a lot of time to learn what you're doing and cross the chasm as well. Who's got the time depends on a whole bunch of factors, but I want to point out primarily that it's quite a lot of work to ask and/or expect of wasmtime maintainers to fully internalize such a large project (and I subjectively thought it had quite a lot of AI noise too)

That makes sense, thanks for the explanation.

To give an update, I’ve ported the fixed code back into my local codebase. While the Rust side now compiles successfully, I hit a static assertion failure during the subsequent NDK build stage. compiler complains that wasmtime_valunion_t and wasmtime_val_raw_t are evaluated to 4-byte alignment instead of the expected 8 bytes:
error: static assertion failed due to requirement '__alignof(wasmtime_valunion) == 8': should be 8-byte aligned
note: expression evaluates to '4 == 8'
To investigate whether this is an inherent alignment difference on 32-bit x86, I wrote a minimal C program and tested it on an i686-linux-android target. The output confirmed that uint64_t and double (and consequently the union) are indeed 4-byte aligned on this platform.

Here is the test code and its execution output:
// test_align.c — compiler target: i686-linux-android
#include <stdalign.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

typedef union {
  int32_t i32;
  int64_t i64;
  float f32;
  double f64;
  void *ptr;
} test_union_t;

int main() {
  printf("sizeof(uint64_t)  = %zu\n", sizeof(uint64_t));
  printf("alignof(uint64_t) = %zu\n", alignof(uint64_t));
  printf("sizeof(double)    = %zu\n", sizeof(double));
  printf("alignof(double)   = %zu\n", alignof(double));
  printf("sizeof(void*)     = %zu\n", sizeof(void *));
  printf("alignof(void*)    = %zu\n", alignof(void *));
  printf("sizeof(test_union_t)  = %zu\n", sizeof(test_union_t));
  printf("alignof(test_union_t) = %zu\n", alignof(test_union_t));
  return 0;
}
Output on device via adb:
sizeof(uint64_t)  = 8
alignof(uint64_t) = 4
sizeof(double)    = 8
alignof(double)   = 4
sizeof(void*)     = 4
alignof(void*)    = 4
sizeof(test_union_t)  = 8
alignof(test_union_t) = 4
<img width="1040" height="790" alt="Image" src="https://github.com/user-attachments/assets/b9177ec5-89a4-483a-b099-3e9d1b5f3c92" />
$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/clang \
    --target=i686-linux-android23 \
    test_align.c -o test_align
adb push test_align /data/local/tmp/
adb shell chmod +x /data/local/tmp/test_align
adb shell /data/local/tmp/test_align
$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/clang \
    --target=armv7-linux-androideabi23 \
    -c test_align_v2.c -o test_align_v2.o
test_align_v2.c:12:16: error: static assertion failed due to requirement '__alignof(test_union_t) == 4': Error: test_union_t is NOT 8-byte aligned!
   12 | _Static_assert(__alignof(test_union_t) == 4,
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
test_align_v2.c:12:40: note: expression evaluates to '8 == 4'
   12 | _Static_assert(__alignof(test_union_t) == 4,
      |                ~~~~~~~~~~~~~~~~~~~~~~~~^~~~
1 error generated.
// test_align_v2.c
#include <stddef.h>
#include <stdint.h>

typedef union {
  int32_t i32;
  int64_t i64;
  float f32;
  double f64;
  void *ptr;
} test_union_t;

_Static_assert(__alignof(test_union_t) == 4, "error: test_union_t is NOT 8-byte aligned!");

int main() { return 0; }
Given this, on 32-bit x86 Android, the natural alignment for these 64-bit types is 4. This seems to be why the static_assert(..., 8) fails during the NDK build unless we explicitly enforce alignment attributes in the headers. How should we best reconcile this ABI discrepancy between Rust and C on 32-bit platforms?

Wasmtime GitHub notifications bot (Jul 01 2026 at 14:52):

alexcrichton commented on issue #13733:

@crowforkotlin this error:

error: static assertion failed due to requirement '__alignof(wasmtime_valunion) == 8': should be 8-byte aligned

you'll want to check where that comes from. I don't see that anywhere in Wasmtime's codebase. In Wasmtime there was a historical assertion with wasmtime_valunion_t (note the "_t" at the end) adjusted in https://github.com/bytecodealliance/wasmtime/pull/13753.

Wasmtime GitHub notifications bot (Jul 02 2026 at 04:01):

crowforkotlin commented on issue #13733:

@alexcrichton Following the merge of your fix for #13753 into the main branch, I have merged main into my main-wasmline branch and successfully completed the Rust compilation and build processes. The subsequent NDK build also passed successfully.

However, a crash occurred during runtime, as detailed below. I will attempt to implement a minimal reproducible sample to provide a relevant testing scenario in due course.
---------------------------- PROCESS STARTED (6756) for package 2026-07-02 11:55:36.274  6756-6756  WasmNative 2026-07-02 11:55:39.788  6756-6756  KotlinWasm 2026-07-02 11:55:39.789  6756-6756  KotlinWasm 2026-07-02 11:55:39.789  6756-6756  KotlinWasm                                                                                                         "platform": "Android",                                                                                                         "content": "Hello from android",                                                                                                         "timeStr": "2026/07/02 11:55:39",                                                                                                         "timeMs": 1782964539788                                                                                                     } 2026-07-02 11:55:39.791  6756-6756  WasmNative 2026-07-02 11:55:39.795  6756-6756  WasmNative 2026-07-02 11:55:39.799  6756-6756  WasmNative 2026-07-02 11:55:39.800  6756-6756  WasmNative 2026-07-02 11:55:39.802  6756-6756  WasmNative 2026-07-02 11:55:39.802  6756-6756  WasmNative 2026-07-02 11:55:39.805  6756-6788  WasmNative 2026-07-02 11:55:39.805  6756-6756  WasmNative 2026-07-02 11:55:39.805  6756-6756  WasmNative --------- beginning of crash 2026-07-02 11:55:39.805  6756-6756  KotlinWasm 2026-07-02 11:55:39.861  6793-6793  DEBUG 2026-07-02 11:55:39.861  6793-6793  DEBUG 2026-07-02 11:55:39.861  6793-6793  DEBUG 2026-07-02 11:55:39.861  6793-6793  DEBUG 2026-07-02 11:55:39.864  6793-6793  DEBUG 2026-07-02 11:55:39.864  6793-6793  DEBUG 2026-07-02 11:55:39.864  6793-6793  DEBUG 2026-07-02 11:55:39.864  6793-6793  DEBUG 2026-07-02 11:55:39.864  6793-6793  DEBUG 2026-07-02 11:55:39.864  6793-6793  DEBUG 2026-07-02 11:55:39.864  6793-6793  DEBUG 2026-07-02 11:55:39.864  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07-02 11:55:40.290  6793-6793  DEBUG 2026-07 [message truncated] 
crow.wasmline ---------------------------- pid-6756 I [Wasmtime] Engine --> Initialized successfully. engine_is_pulley=true crow.wasmline I [WasmLoader] execute action=TimeSyncService.timeSync crow.wasmline I [WasmLoader] artifact=/data/user/0/crow.wasmline/cache/plugin.pwasm crow.wasmline I [WasmLoader] input={ crow.wasmline I [Wasmtime] Module --> Deserializing precompiled artifact for /data/user/0/crow.wasmline/cache/plugin.pwasm crow.wasmline I [Wasmtime] Module (Unsafe) --> Loaded and cached: /data/user/0/crow.wasmline/cache/plugin.pwasm crow.wasmline I [Wasmtime] Session --> 1. Setup wasi success. crow.wasmline I [Wasmtime] Session --> 2. Register host functions success. crow.wasmline I [Wasmtime] Session --> 3. Instantiate linker success. crow.wasmline I [Wasmtime] Session --> 4. Export memory success. crow.wasmline I [Wasmtime-Wasi] logger -> [Kotlin Wasi] Plugin main executed crow.wasmline I [Wasmtime] Session --> 6. Ran wasm init export '__wasmline_wasi_init'. crow.wasmline I [Wasmtime] Session --> 7. Initialized success: /data/user/0/crow.wasmline/cache/plugin.pwasm crow.wasmline I [WasmLoader] load success in 6 ms pid-6793 A *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** pid-6793 A Build fingerprint: 'google/sdk_gphone_x86/generic_x86_arm:11/RSR1.240422.006/12134477:userdebug/dev-keys' pid-6793 A Revision: '0' pid-6793 A ABI: 'x86' pid-6793 A Timestamp: 2026-07-02 11:55:39+0800 pid-6793 A pid: 6756, tid: 6756, name: crow.wasmline >>> crow.wasmline <<< pid-6793 A uid: 10178 pid-6793 A signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr -------- pid-6793 A Abort message: 'unknown wasmtime_valkind_t: 48' pid-6793 A eax 00000000 ebx 00001a64 ecx 00001a64 edx 00000006 pid-6793 A edi e357c80e esi ff820550 pid-6793 A ebp e8d66b80 esp ff8204f8 eip e8d66b89 pid-6793 A backtrace: pid-6793 A #00 pc 00000b89 [vdso] (__kernel_vsyscall+9) pid-6793 A #01 pc 0005ad58 /apex/com.android.runtime/lib/bionic/libc.so (syscall+40) (BuildId: f10845bd3cfdcd0076d81b46b7a06459) pid-6793 A #02 pc 00076501 /apex/com.android.runtime/lib/bionic/libc.so (abort+209) (BuildId: f10845bd3cfdcd0076d81b46b7a06459) pid-6793 A #03 pc 000cb9ac /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #04 pc 000a837b /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #05 pc 000ccd79 /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #06 pc 00093253 /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #07 pc 000a8454 /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #08 pc 000a800f /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #09 pc 000cc9e0 /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #10 pc 000cc978 /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #11 pc 000ccda2 /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #12 pc 0008ddbb /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #13 pc 001a3a79 /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #14 pc 001a5c34 /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #15 pc 0008608d /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750) pid-6793 A #16 pc 00081473 /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)

Wasmtime GitHub notifications bot (Jul 02 2026 at 04:01):

crowforkotlin edited a comment on issue #13733:

@alexcrichton Following the merge of your fix for #13753 into the main branch, I have merged main into my main-wasmline branch and successfully completed the Rust compilation and build processes. The subsequent NDK build also passed successfully.

However, a crash occurred during runtime, as detailed below. I will attempt to implement a minimal reproducible sample to provide a relevant testing scenario in due course.

Abort message: 'unknown wasmtime_valkind_t: 48'

---------------------------- PROCESS STARTED (6756) for package crow.wasmline ----------------------------
2026-07-02 11:55:36.274  6756-6756  WasmNative              pid-6756                             I  [Wasmtime] Engine --> Initialized successfully. engine_is_pulley=true
2026-07-02 11:55:39.788  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] execute action=TimeSyncService.timeSync
2026-07-02 11:55:39.789  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] artifact=/data/user/0/crow.wasmline/cache/plugin.pwasm
2026-07-02 11:55:39.789  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] input={
                                                                                                        "platform": "Android",
                                                                                                        "content": "Hello from android",
                                                                                                        "timeStr": "2026/07/02 11:55:39",
                                                                                                        "timeMs": 1782964539788
                                                                                                    }
2026-07-02 11:55:39.791  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Module --> Deserializing precompiled artifact for /data/user/0/crow.wasmline/cache/plugin.pwasm
2026-07-02 11:55:39.795  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Module (Unsafe) --> Loaded and cached: /data/user/0/crow.wasmline/cache/plugin.pwasm
2026-07-02 11:55:39.799  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 1. Setup wasi success.
2026-07-02 11:55:39.800  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 2. Register host functions success.
2026-07-02 11:55:39.802  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 3. Instantiate linker success.
2026-07-02 11:55:39.802  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 4. Export memory success.
2026-07-02 11:55:39.805  6756-6788  WasmNative              crow.wasmline                        I  [Wasmtime-Wasi] logger -> [Kotlin Wasi] Plugin main executed
2026-07-02 11:55:39.805  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 6. Ran wasm init export '__wasmline_wasi_init'.
2026-07-02 11:55:39.805  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 7. Initialized success: /data/user/0/crow.wasmline/cache/plugin.pwasm
--------- beginning of crash
2026-07-02 11:55:39.805  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] load success in 6 ms
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  Build fingerprint: 'google/sdk_gphone_x86/generic_x86_arm:11/RSR1.240422.006/12134477:userdebug/dev-keys'
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  Revision: '0'
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  ABI: 'x86'
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  Timestamp: 2026-07-02 11:55:39+0800
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  pid: 6756, tid: 6756, name: crow.wasmline  >>> crow.wasmline <<<
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  uid: 10178
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  Abort message: 'unknown wasmtime_valkind_t: 48'
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A      eax 00000000  ebx 00001a64  ecx 00001a64  edx 00000006
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A      edi e357c80e  esi ff820550
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A      ebp e8d66b80  esp ff8204f8  eip e8d66b89
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A  backtrace:
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #00 pc 00000b89  [vdso] (__kernel_vsyscall+9)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #01 pc 0005ad58  /apex/com.android.runtime/lib/bionic/libc.so (syscall+40) (BuildId: f10845bd3cfdcd0076d81b46b7a06459)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #02 pc 00076501  /apex/com.android.runtime/lib/bionic/libc.so (abort+209) (BuildId: f10845bd3cfdcd0076d81b46b7a06459)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #03 pc 000cb9ac  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #04 pc 000a837b  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #05 pc 000ccd79  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #06 pc 00093253  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #07 pc 000a8454  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #08 pc 000a800f  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #09 pc 000cc9e0  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #10 pc 000cc978  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #11 pc 000ccda2  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #12 pc 0008ddbb  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #13 pc 001a3a79  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #14 pc 001a5c34  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #15 pc 0008608d  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #16 pc 00081473  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.
[message truncated]

Wasmtime GitHub notifications bot (Jul 02 2026 at 04:02):

crowforkotlin edited a comment on issue #13733:

However, a crash occurred during runtime, as detailed below. I will work on creating a minimal reproducible sample to provide a testing scenario, although it is not yet complete at this moment.

Abort message: 'unknown wasmtime_valkind_t: 48'

---------------------------- PROCESS STARTED (6756) for package crow.wasmline ----------------------------
2026-07-02 11:55:36.274  6756-6756  WasmNative              pid-6756                             I  [Wasmtime] Engine --> Initialized successfully. engine_is_pulley=true
2026-07-02 11:55:39.788  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] execute action=TimeSyncService.timeSync
2026-07-02 11:55:39.789  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] artifact=/data/user/0/crow.wasmline/cache/plugin.pwasm
2026-07-02 11:55:39.789  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] input={
                                                                                                        "platform": "Android",
                                                                                                        "content": "Hello from android",
                                                                                                        "timeStr": "2026/07/02 11:55:39",
                                                                                                        "timeMs": 1782964539788
                                                                                                    }
2026-07-02 11:55:39.791  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Module --> Deserializing precompiled artifact for /data/user/0/crow.wasmline/cache/plugin.pwasm
2026-07-02 11:55:39.795  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Module (Unsafe) --> Loaded and cached: /data/user/0/crow.wasmline/cache/plugin.pwasm
2026-07-02 11:55:39.799  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 1. Setup wasi success.
2026-07-02 11:55:39.800  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 2. Register host functions success.
2026-07-02 11:55:39.802  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 3. Instantiate linker success.
2026-07-02 11:55:39.802  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 4. Export memory success.
2026-07-02 11:55:39.805  6756-6788  WasmNative              crow.wasmline                        I  [Wasmtime-Wasi] logger -> [Kotlin Wasi] Plugin main executed
2026-07-02 11:55:39.805  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 6. Ran wasm init export '__wasmline_wasi_init'.
2026-07-02 11:55:39.805  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 7. Initialized success: /data/user/0/crow.wasmline/cache/plugin.pwasm
--------- beginning of crash
2026-07-02 11:55:39.805  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] load success in 6 ms
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  Build fingerprint: 'google/sdk_gphone_x86/generic_x86_arm:11/RSR1.240422.006/12134477:userdebug/dev-keys'
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  Revision: '0'
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  ABI: 'x86'
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  Timestamp: 2026-07-02 11:55:39+0800
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  pid: 6756, tid: 6756, name: crow.wasmline  >>> crow.wasmline <<<
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  uid: 10178
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  Abort message: 'unknown wasmtime_valkind_t: 48'
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A      eax 00000000  ebx 00001a64  ecx 00001a64  edx 00000006
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A      edi e357c80e  esi ff820550
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A      ebp e8d66b80  esp ff8204f8  eip e8d66b89
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A  backtrace:
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #00 pc 00000b89  [vdso] (__kernel_vsyscall+9)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #01 pc 0005ad58  /apex/com.android.runtime/lib/bionic/libc.so (syscall+40) (BuildId: f10845bd3cfdcd0076d81b46b7a06459)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #02 pc 00076501  /apex/com.android.runtime/lib/bionic/libc.so (abort+209) (BuildId: f10845bd3cfdcd0076d81b46b7a06459)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #03 pc 000cb9ac  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #04 pc 000a837b  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #05 pc 000ccd79  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #06 pc 00093253  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #07 pc 000a8454  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #08 pc 000a800f  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #09 pc 000cc9e0  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #10 pc 000cc978  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #11 pc 000ccda2  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #12 pc 0008ddbb  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #13 pc 001a3a79  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #14 pc 001a5c34  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #15 pc 0008608d  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #16 pc 00081473  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==
[message truncated]

Wasmtime GitHub notifications bot (Jul 02 2026 at 07:53):

crowforkotlin edited a comment on issue #13733:

However, a crash occurred during runtime, as detailed below. I plan to create a minimal reproducible example to provide a test case.

Abort message: 'unknown wasmtime_valkind_t: 48'

---------------------------- PROCESS STARTED (6756) for package crow.wasmline ----------------------------
2026-07-02 11:55:36.274  6756-6756  WasmNative              pid-6756                             I  [Wasmtime] Engine --> Initialized successfully. engine_is_pulley=true
2026-07-02 11:55:39.788  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] execute action=TimeSyncService.timeSync
2026-07-02 11:55:39.789  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] artifact=/data/user/0/crow.wasmline/cache/plugin.pwasm
2026-07-02 11:55:39.789  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] input={
                                                                                                        "platform": "Android",
                                                                                                        "content": "Hello from android",
                                                                                                        "timeStr": "2026/07/02 11:55:39",
                                                                                                        "timeMs": 1782964539788
                                                                                                    }
2026-07-02 11:55:39.791  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Module --> Deserializing precompiled artifact for /data/user/0/crow.wasmline/cache/plugin.pwasm
2026-07-02 11:55:39.795  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Module (Unsafe) --> Loaded and cached: /data/user/0/crow.wasmline/cache/plugin.pwasm
2026-07-02 11:55:39.799  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 1. Setup wasi success.
2026-07-02 11:55:39.800  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 2. Register host functions success.
2026-07-02 11:55:39.802  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 3. Instantiate linker success.
2026-07-02 11:55:39.802  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 4. Export memory success.
2026-07-02 11:55:39.805  6756-6788  WasmNative              crow.wasmline                        I  [Wasmtime-Wasi] logger -> [Kotlin Wasi] Plugin main executed
2026-07-02 11:55:39.805  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 6. Ran wasm init export '__wasmline_wasi_init'.
2026-07-02 11:55:39.805  6756-6756  WasmNative              crow.wasmline                        I  [Wasmtime] Session --> 7. Initialized success: /data/user/0/crow.wasmline/cache/plugin.pwasm
--------- beginning of crash
2026-07-02 11:55:39.805  6756-6756  KotlinWasm              crow.wasmline                        I  [WasmLoader] load success in 6 ms
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  Build fingerprint: 'google/sdk_gphone_x86/generic_x86_arm:11/RSR1.240422.006/12134477:userdebug/dev-keys'
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  Revision: '0'
2026-07-02 11:55:39.861  6793-6793  DEBUG                   pid-6793                             A  ABI: 'x86'
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  Timestamp: 2026-07-02 11:55:39+0800
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  pid: 6756, tid: 6756, name: crow.wasmline  >>> crow.wasmline <<<
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  uid: 10178
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A  Abort message: 'unknown wasmtime_valkind_t: 48'
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A      eax 00000000  ebx 00001a64  ecx 00001a64  edx 00000006
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A      edi e357c80e  esi ff820550
2026-07-02 11:55:39.864  6793-6793  DEBUG                   pid-6793                             A      ebp e8d66b80  esp ff8204f8  eip e8d66b89
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A  backtrace:
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #00 pc 00000b89  [vdso] (__kernel_vsyscall+9)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #01 pc 0005ad58  /apex/com.android.runtime/lib/bionic/libc.so (syscall+40) (BuildId: f10845bd3cfdcd0076d81b46b7a06459)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #02 pc 00076501  /apex/com.android.runtime/lib/bionic/libc.so (abort+209) (BuildId: f10845bd3cfdcd0076d81b46b7a06459)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #03 pc 000cb9ac  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #04 pc 000a837b  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #05 pc 000ccd79  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #06 pc 00093253  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #07 pc 000a8454  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #08 pc 000a800f  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #09 pc 000cc9e0  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #10 pc 000cc978  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #11 pc 000ccda2  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #12 pc 0008ddbb  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #13 pc 001a3a79  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #14 pc 001a5c34  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #15 pc 0008608d  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850a0fdc0b912750)
2026-07-02 11:55:40.290  6793-6793  DEBUG                   pid-6793                             A        #16 pc 00081473  /data/app/~~ZAjAog3AgKi7mqQh-CIg2g==/crow.wasmline-s9YdTkzHnQThblyMLfGSrA==/lib/x86/libwasmline.so (BuildId: d5fba98fe601d678b562765c850
[message truncated]

Wasmtime GitHub notifications bot (Jul 02 2026 at 14:15):

alexcrichton commented on issue #13733:

When using the C API that could happen for any number of reasons. There could be UB in C, UB in the bindings, a bug in Wasmtime, a bug in layouts, etc. There's really no way to know what's actually going on without something to reproduce with unfortunately.

Wasmtime GitHub notifications bot (Jul 04 2026 at 08:42):

crowforkotlin commented on issue #13733:

When using the C API that could happen for any number of reasons. There could be UB in C, UB in the bindings, a bug in Wasmtime, a bug in layouts, etc. There's really no way to know what's actually going on without something to reproduce with unfortunately.

@alexcrichton https://github.com/crowforkotlin/wasmtime_c_api_32bit_issues

I have resubmitted the code, and the testing and verification process has now become significantly more straightforward. Furthermore, I have discovered a resolution that has been successfully verified in my local environment. This solution effectively addresses the crashes occurring at both compile-time and runtime: replacing __alignof with the C11 standard _Alignof or the C23 standard alignof.
-  static_assert(__alignof(wasmtime_valunion_t) == __alignof(uint64_t), "should be aligned to u64");
-  static_assert(__alignof(wasmtime_val_raw_t) == __alignof(uint64_t), "should be aligned to u64");
+  static_assert(_Alignof(wasmtime_valunion_t) == _Alignof(uint64_t), "should be aligned to u64");
+  static_assert(_Alignof(wasmtime_val_raw_t) == _Alignof(uint64_t), "should be aligned to u64");
The execution results are demonstrated below:
export WASMTIME_DIR=~/develop/github/wasmtime/
bash build-local.sh
bash run-local.sh
=== Compile with upstream headers ===
Compile OK

=== Run ===
--- C-side layout (i686) ---
__alignof(uint64_t)        = 8  (preferred, GCC extension)
_Alignof(uint64_t)         = 4  (ABI minimum, C11 standard)
sizeof(wasmtime_val_t)     = 20
__alignof(wasmtime_val_t)  = 4
offsetof(val_t, kind)      = 0
offsetof(val_t, of)        = 4
sizeof(wasmtime_valunion_t)= 16
__alignof(wasmtime_valunion_t) = 4

Calling add(10, 32)...
Result: 42 (expected 42) -> PASS

Wasmtime GitHub notifications bot (Jul 06 2026 at 03:03):

alexcrichton commented on issue #13733:

Ah I had no idea about that! Would you be up for sending a PR to update the header?

Wasmtime GitHub notifications bot (Jul 07 2026 at 08:55):

crowforkotlin edited issue #13733:

Issue Description

On 32-bit platforms (e.g., i686-linux-android, armv7-linux-androideabi), the C API header wasmtime/val.h contains static_assert checks that require wasmtime_valunion_t and wasmtime_val_raw_t to be 8-byte aligned:
static_assert(__alignof(wasmtime_valunion_t) == 8, "should be 8-byte aligned");
static_assert(__alignof(wasmtime_val_raw_t) == 8, "should be 8-byte aligned");
However, on 32-bit platforms, int64_t and double only have 4-byte alignment in the C ABI, causing these assertions to fail at compile time.

Additionally, even if the assertions are bypassed, there is a layout mismatch between Rust and C on 32-bit platforms:

Rust #[repr(C)] C (original val.h)

union alignment 8 (Rust's i64/u64 are always 8-byte aligned) 4 (C ABI int64_t on 32-bit)

wasmtime_val_t.of offset 8 4

wasmtime_val_t size 32 20

This causes the C side to read garbage data for the kind field (e.g., unknown wasmtime_valkind_t: 16), leading to a SIGABRT crash at runtime when calling wasmtime_func_call.

Reproduction

Build libwasmtime.a for i686-linux-android (32-bit x86 Android)

Include wasmtime/val.h from C++ code compiled with the Android NDK (x86 target)

Compile fails with static_assert errors

If assertions are removed, runtime crash occurs: Abort message: 'unknown wasmtime_valkind_t: <garbage>'

Crash Log (x86 Android Emulator)
Abort message: 'unknown wasmtime_valkind_t: 16'
signal 6 (SIGABRT), code -1 (SI_QUEUE)
backtrace:
  #14 pc ... libwasmline.so (wasmtime_func_call+192)
  #15 pc ... libwasmline.so (wasmline::Session::invokeInbound+465)
  ...
Proposed Fix

Force 8-byte alignment on both C and Rust sides to ensure consistent layout across all platforms:

crates/c-api/include/wasmtime/val.h:
-typedef union wasmtime_valunion {
+typedef union alignas(8) wasmtime_valunion {

-typedef union wasmtime_val_raw {
+typedef union alignas(8) wasmtime_val_raw {

-typedef struct wasmtime_val {
+typedef struct alignas(8) wasmtime_val {
crates/c-api/src/val.rs:
-#[repr(C)]
+#[repr(C, align(8))]
 pub struct wasmtime_val_t {

-#[repr(C)]
+#[repr(C, align(8))]
 pub union wasmtime_val_union {
And update the compile-time assertion:
 const _: () = {
-    assert!(std::mem::size_of::<wasmtime_val_union>() <= 24);
-    assert!(std::mem::align_of::<wasmtime_val_union>() == std::mem::align_of::<u64>());
+    assert!(std::mem::size_of::<wasmtime_val_union>() <= 32);
+    assert!(std::mem::align_of::<wasmtime_val_union>() == 8);
 };
Impact

Platform Before Fix After Fix

x86_64 / aarch64 (64-bit) align=8, works :check: align=8, no change :check:

x86 / armv7a (32-bit) align=4, compile fails / runtime crash :cross_mark: align=8, works :check:

64-bit platforms: zero impact (alignas(8) is redundant, natural alignment is already 8)

32-bit platforms: fixes compile-time assertion failure and runtime layout mismatch

Memory overhead on 32-bit: ~12 bytes per wasmtime_val_t (negligible for typical usage)

API compatibility: no changes to type names or function signatures

Environment

Forked Wasmtime version: 45.0.6 (custom features pulley-min [x86/armv7a] )

Affected targets: i686-linux-android, armv7-linux-androideabi (and potentially other 32-bit targets)

Discovered while building wasmline (a Wasm plugin framework) with Pulley interpreter on 32-bit Android

Fix

https://github.com/crowforkotlin/wasmtime/commit/e24159c780779c7f36554c7578b94bd5b37708a0#diff-ed790182a50ae9da596d84eb7f31ac26eb4af8c326a9d19a637ab903c7a2091b

Result After Fix

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/e9c742d0-a673-4eae-b8eb-16e4ac49973e" />

	Rust `#[repr(C)]`	C (original `val.h`)
union alignment	8 (Rust's `i64`/`u64` are always 8-byte aligned)	4 (C ABI `int64_t` on 32-bit)
`wasmtime_val_t.of` offset	8	4
`wasmtime_val_t` size	32	20

Platform	Before Fix	After Fix
x86_64 / aarch64 (64-bit)	align=8, works :check:	align=8, no change :check:
x86 / armv7a (32-bit)	align=4, compile fails / runtime crash :cross_mark:	align=8, works :check:

Wasmtime GitHub notifications bot (Jul 08 2026 at 14:28):

crowforkotlin closed issue #13733:

Issue Description

On 32-bit platforms (e.g., i686-linux-android, armv7-linux-androideabi), the C API header wasmtime/val.h contains static_assert checks that require wasmtime_valunion_t and wasmtime_val_raw_t to be 8-byte aligned:
static_assert(__alignof(wasmtime_valunion_t) == 8, "should be 8-byte aligned");
static_assert(__alignof(wasmtime_val_raw_t) == 8, "should be 8-byte aligned");
However, on 32-bit platforms, int64_t and double only have 4-byte alignment in the C ABI, causing these assertions to fail at compile time.

Additionally, even if the assertions are bypassed, there is a layout mismatch between Rust and C on 32-bit platforms:

Rust #[repr(C)] C (original val.h)

union alignment 8 (Rust's i64/u64 are always 8-byte aligned) 4 (C ABI int64_t on 32-bit)

wasmtime_val_t.of offset 8 4

wasmtime_val_t size 32 20

This causes the C side to read garbage data for the kind field (e.g., unknown wasmtime_valkind_t: 16), leading to a SIGABRT crash at runtime when calling wasmtime_func_call.

Reproduction

Build libwasmtime.a for i686-linux-android (32-bit x86 Android)

Include wasmtime/val.h from C++ code compiled with the Android NDK (x86 target)

Compile fails with static_assert errors

If assertions are removed, runtime crash occurs: Abort message: 'unknown wasmtime_valkind_t: <garbage>'

Crash Log (x86 Android Emulator)
Abort message: 'unknown wasmtime_valkind_t: 16'
signal 6 (SIGABRT), code -1 (SI_QUEUE)
backtrace:
  #14 pc ... libwasmline.so (wasmtime_func_call+192)
  #15 pc ... libwasmline.so (wasmline::Session::invokeInbound+465)
  ...
Proposed Fix

Force 8-byte alignment on both C and Rust sides to ensure consistent layout across all platforms:

crates/c-api/include/wasmtime/val.h:
-typedef union wasmtime_valunion {
+typedef union alignas(8) wasmtime_valunion {

-typedef union wasmtime_val_raw {
+typedef union alignas(8) wasmtime_val_raw {

-typedef struct wasmtime_val {
+typedef struct alignas(8) wasmtime_val {
crates/c-api/src/val.rs:
-#[repr(C)]
+#[repr(C, align(8))]
 pub struct wasmtime_val_t {

-#[repr(C)]
+#[repr(C, align(8))]
 pub union wasmtime_val_union {
And update the compile-time assertion:
 const _: () = {
-    assert!(std::mem::size_of::<wasmtime_val_union>() <= 24);
-    assert!(std::mem::align_of::<wasmtime_val_union>() == std::mem::align_of::<u64>());
+    assert!(std::mem::size_of::<wasmtime_val_union>() <= 32);
+    assert!(std::mem::align_of::<wasmtime_val_union>() == 8);
 };
Impact

Platform Before Fix After Fix

x86_64 / aarch64 (64-bit) align=8, works :check: align=8, no change :check:

x86 / armv7a (32-bit) align=4, compile fails / runtime crash :cross_mark: align=8, works :check:

64-bit platforms: zero impact (alignas(8) is redundant, natural alignment is already 8)

32-bit platforms: fixes compile-time assertion failure and runtime layout mismatch

Memory overhead on 32-bit: ~12 bytes per wasmtime_val_t (negligible for typical usage)

API compatibility: no changes to type names or function signatures

Environment

Forked Wasmtime version: 45.0.6 (custom features pulley-min [x86/armv7a] )

Affected targets: i686-linux-android, armv7-linux-androideabi (and potentially other 32-bit targets)

Discovered while building wasmline (a Wasm plugin framework) with Pulley interpreter on 32-bit Android

Fix

https://github.com/crowforkotlin/wasmtime/commit/e24159c780779c7f36554c7578b94bd5b37708a0#diff-ed790182a50ae9da596d84eb7f31ac26eb4af8c326a9d19a637ab903c7a2091b

Result After Fix

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/e9c742d0-a673-4eae-b8eb-16e4ac49973e" />

	Rust `#[repr(C)]`	C (original `val.h`)
union alignment	8 (Rust's `i64`/`u64` are always 8-byte aligned)	4 (C ABI `int64_t` on 32-bit)
`wasmtime_val_t.of` offset	8	4
`wasmtime_val_t` size	32	20

Platform	Before Fix	After Fix
x86_64 / aarch64 (64-bit)	align=8, works :check:	align=8, no change :check:
x86 / armv7a (32-bit)	align=4, compile fails / runtime crash :cross_mark:	align=8, works :check:

Last updated: Jul 29 2026 at 05:03 UTC