Stream: git-wasmtime

Topic: wasmtime / issue #7558 Different output when running the ...

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2023 at 09:08):

XinyuShe opened issue #7558:

filea11.zip is a simd file randomly constructed, without a source file. And I test it in AOT mode
![image](https://github.com/bytecodealliance/wasmtime/assets/60457190/7f10a1f7-1aec-450f-93df-4cd52835edf1)

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

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2023 at 10:37):

XinyuShe edited issue #7558:

filea11.zip is a simd file randomly constructed, without a source file. And I test it in AOT mode
![image](https://github.com/bytecodealliance/wasmtime/assets/60457190/7f10a1f7-1aec-450f-93df-4cd52835edf1)

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

```[tasklist]

Tasks

~~~

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2023 at 10:37):

XinyuShe edited issue #7558:

filea11.zip is a simd file randomly constructed, without a source file. And I test it in AOT mode
![image](https://github.com/bytecodealliance/wasmtime/assets/60457190/7f10a1f7-1aec-450f-93df-4cd52835edf1)

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

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2023 at 12:41):

tschneidereit commented on issue #7558:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2023 at 15:11):

alexcrichton commented on issue #7558:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2023 at 16:01):

tschneidereit commented on issue #7558:

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!

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2023 at 16:23):

XinyuShe commented on issue #7558:

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

view this post on Zulip Wasmtime GitHub notifications bot (Nov 20 2023 at 18:39):

alexcrichton closed issue #7558:

filea11.zip is a simd file randomly constructed, without a source file. And I test it in AOT mode
![image](https://github.com/bytecodealliance/wasmtime/assets/60457190/7f10a1f7-1aec-450f-93df-4cd52835edf1)

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

view this post on Zulip Wasmtime GitHub notifications bot (Dec 12 2023 at 07:53):

abc767234318 commented on issue #7558:

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.

Hi, could you please explain why wasmtime converted the i32 to u64 instead of u32? The addressing space of 4G can be covered with u32.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 12 2023 at 11:34):

abc767234318 deleted a comment on issue #7558:

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.

Hi, could you please explain why wasmtime converted the i32 to u64 instead of u32? The addressing space of 4G can be covered with u32.

Last updated: Dec 23 2024 at 12:05 UTC