Different output when running the same wasm file in aot mode

[XinyuShe]

filea11.zip is a simd file randomly constructed, without a source file. And I test it in AOT mode

Because I used an old version of wasmtime in the above picture, I downloaded the latest version of wasmtime, 14.0.4, and retested, but the results did not change. I also tested the latest versions of wasmer and wamr, both of which were different from wasmtime.

wasmtime

root@22a831657e73:# ../wasmtime --version
wasmtime-cli 14.0.4
root@22a831657e73:a# ../wasmtime --allow-precompiled --invoke main filea11.cwasm
Error: failed to run main module `filea11.cwasm`

Caused by:
    0: failed to instantiate "filea11.cwasm"
    1: wasm trap: out of bounds memory access

wasmer

>wasmer.exe run -e main filea11.wasm
24695612705472451393634029802101417489 24695612705472451393634029802101417489 24695612705472451393634029802101417489 24695612705472451393634029802101417489 24695612705472451393634029802101417489 24695612705472451393634029802101417489 24695612705472451393634029802101417489 24695612705472451393634029802101417489
>wasmer --version
wasmer 4.2.3

wamr

root@4252f5ec38df:/home/sxy/exp# iwasm --version
iwasm 1.2.3
root@4252f5ec38df:/home/sxy/exp# iwasm --heap-size=0 -f main filea11.wasm 
<0xcf1af7a4d7a82611 0x129433b64d1d090d>:v128,<0xcf1af7a4d7a82611 0x129433b64d1d090d>:v128,<0xcf1af7a4d7a82611 0x129433b64d1d090d>:v128,<0xcf1af7a4d7a82611 0x129433b64d1d090d>:v128,<0xcf1af7a4d7a82611 0x129433b64d1d090d>:v128,<0xcf1af7a4d7a82611 0x129433b64d1d090d>:v128,<0xcf1af7a4d7a82611 0x129433b64d1d090d>:v128,<0xcf1af7a4d7a82611 0x129433b64d1d090d>:v128

[tschneidereit]

This isn't related to AOT compilation: the same error occurs when running the wasm file directly.

The issue seems to be that the wasm file contains a data segment with a negative offset of -79158787. By my reading of the spec, wasmtime's behavior is correct here. I'm not sure what Wasmer and WAMR are doing to get anything running at all.

[alexcrichton]

Ah actually this is indeed a bug in Wasmtime (fixed here). The negative offset should be interpreted as a 32-bit unsigned value and because the memory here is of maximal size (4G) it should be valid. The bug was that an integer cast in Wasmtime sign-extended the value to 64-bits instead of zero-extending which produced the error seen here.

[tschneidereit]

wow, that is a fascinating and surprising wrinkle of the spec. Apologies for the wrong answer @XinyuShe, and thank you for the correction and bugfix, @alexcrichton!

[XinyuShe]

That's okay, I'm happy to be able to help you all. @tschneidereit