Stream: git-wasmtime

Topic: wasmtime / issue #11419 File path dependent execution beh...

Wasmtime GitHub notifications bot (Aug 12 2025 at 08:19):

erxiaozhou opened issue #11419:

Summary

Wasmtime exhibits non-deterministic behavior where identical WebAssembly files produce different execution results based solely on their file paths.

Steps to Reproduce

1. Create two identical WASM files with different names:
   case:

rt3.zip

# Files are byte-for-byte identical
md5sum tt/rt3.wasm tt/combine_out.wasm
# b19d889a5d6828ace636f2669d68c919  tt/rt3.wasm
# b19d889a5d6828ace636f2669d68c919  tt/combine_out.wasm

2. Run both files with identical Wasmtime options:

wasmtime run   tt/rt3.wasm
wasmtime run  tt/combine_out.wasm

Expected Results

Both executions should produce identical results since the files are byte-for-byte identical.

Actual Results

• tt/rt3.wasm: Executes successfully (returncode 0)
• tt/combine_out.wasm: Fails with indirect call type mismatch error

Error: failed to run main module `tt/combine_out.wasm`

Caused by:
    0: failed to invoke command default
    1: wasm trap: indirect call type mismatch
       wasm backtrace:
           0: <unknown>!<wasm function 38>
           1: <unknown>!<wasm function 39>

Additional Evidence

Environment

• Wasmtime version: v35.0.0
• Operating system: Ubuntu
• Architecture: x86_64
• Compilation: The WASM file appears to be compiled with optimization and contains indirect calls

The following workarounds were tested but did not resolve the issue:

• --disable-cache
• --disable-address-map
• --disable-memory-init-cow
• --opt-level 0
• Clearing ~/.cache/wasmtime/
• Using absolute paths vs relative paths

I'm not sure whether the behavior can be reproduced, because it seems to be associated with the host.

Wasmtime GitHub notifications bot (Aug 12 2025 at 14:55):

alexcrichton commented on issue #11419:

This program imports "wasi_snapshot_preview1" "args_get" which is a source of non-determinisim for when the program is run under two paths. I've seen bugs in programs in the past related to the length of a filename causing different malloc behavior. Do you have reason to believe this is a bug in Wasmtime and not a bug in the guest? For example if the guest traps if the filename is larger than 10 characters that'll look like different behavior when in fact it's a bug in the guest. Do you, for example, have the source code this guest was generated from?

I might recommend reading over https://docs.wasmtime.dev/contributing-fuzzing.html#external-fuzzing-campaigns as well if you're doing fuzzing.

Wasmtime GitHub notifications bot (Aug 14 2025 at 04:54):

erxiaozhou closed issue #11419:

Summary

Wasmtime exhibits non-deterministic behavior where identical WebAssembly files produce different execution results based solely on their file paths.

Steps to Reproduce

1. Create two identical WASM files with different names:
   case:

rt3.zip

# Files are byte-for-byte identical
md5sum tt/rt3.wasm tt/combine_out.wasm
# b19d889a5d6828ace636f2669d68c919  tt/rt3.wasm
# b19d889a5d6828ace636f2669d68c919  tt/combine_out.wasm

2. Run both files with identical Wasmtime options:

wasmtime run   tt/rt3.wasm
wasmtime run  tt/combine_out.wasm

Expected Results

Both executions should produce identical results since the files are byte-for-byte identical.

Actual Results

• tt/rt3.wasm: Executes successfully (returncode 0)
• tt/combine_out.wasm: Fails with indirect call type mismatch error

Error: failed to run main module `tt/combine_out.wasm`

Caused by:
    0: failed to invoke command default
    1: wasm trap: indirect call type mismatch
       wasm backtrace:
           0: <unknown>!<wasm function 38>
           1: <unknown>!<wasm function 39>

Additional Evidence

Environment

• Wasmtime version: v35.0.0
• Operating system: Ubuntu
• Architecture: x86_64
• Compilation: The WASM file appears to be compiled with optimization and contains indirect calls

The following workarounds were tested but did not resolve the issue:

• --disable-cache
• --disable-address-map
• --disable-memory-init-cow
• --opt-level 0
• Clearing ~/.cache/wasmtime/
• Using absolute paths vs relative paths

I'm not sure whether the behavior can be reproduced, because it seems to be associated with the host.

Last updated: Dec 06 2025 at 07:03 UTC