Different output when running a same binary

[XinyuShe]

trafficstars

I used the AOT mode of different runtimes to run randomly generated wasm binaries, and the output from wamr and wasmedge are different from the others. filea5770.zip

wamr and wasmedge in AOT

root@4252f5ec38df:/home/sxy/exp# /a/WasmEdge-0.13.5-Linux/bin/wasmedge_0.13.5 compile filea5770.wasm filea5770.wasm.so ; /a/WasmEdge-0.13.5-Linux/bin/wasmedge_0.13.5 --reactor filea5770.wasm.so main
[2023-11-28 04:10:59.044] [info] compile start
[2023-11-28 04:10:59.045] [info] verify start
[2023-11-28 04:10:59.045] [info] optimize start
[2023-11-28 04:10:59.049] [info] codegen start
[2023-11-28 04:10:59.053] [info] output start
[2023-11-28 04:10:59.055] [info] compile done
[2023-11-28 04:10:59.072] [error] execution failed: out of bounds memory access, Code: 0x88
[2023-11-28 04:10:59.072] [error]     When executing function name: "main"
root@4252f5ec38df:/home/sxy/exp# /home/wasm-micro-runtime/wamr-compiler/build/wamrc --bounds-checks=1 -o filea5770.wasm.aot filea5770.wasm ; /home/wasm-micro-runtime/product-mini/platforms/linux/build/iwasm --heap-size=0 -f main filea5770.wasm.aot
Create AoT compiler with:
  target:        x86_64
  target cpu:    znver3
  target triple: x86_64-unknown-linux-gnu
  cpu features:  
  opt level:     3
  size level:    3
  output format: AoT file
Compile success, file filea5770.wasm.aot was generated.
Exception: out of bounds memory access

wamr in JIT

root@4252f5ec38df:/home/sxy/exp# iwasm --heap-size=0 -f main filea5770.wasm
Exception: out of bounds memory access

wasmtime and wasmer in AOT

root@4252f5ec38df:/a# wasmtime_16 run --invoke main filea5770.wasm 
warning: using `--invoke` with a function that returns values is experimental and may break in the future
5192217631581239183807531959944959
5192217631581239183807531959944959
5192217631581239183807531959944959
5192217631581239183807531959944959

$ ./wasmer.exe run -e main filea5770.wasm
5192217631581239183807531959944959 5192217631581239183807531959944959 5192217631581239183807531959944959 5192217631581239183807531959944959

wasmtime and wasmer in JIT

root@4252f5ec38df:/a# wasmtime_16 compile filea5770.wasm -o filea5770.cwasm ; wasmtime_16  --allow-precompiled --invoke main  filea5770.cwasm
warning: using `--invoke` with a function that returns values is experimental and may break in the future
5192217631581239183807531959944959
5192217631581239183807531959944959
5192217631581239183807531959944959
5192217631581239183807531959944959

$ ./wasmer.exe compile filea5770.wasm  -o filea5770.wasmu ; ./wasmer.exe run -e main filea5770.wasmu
Compiler: cranelift
Target: x86_64-pc-windows-msvc
✔ File compiled successfully to `filea5770.wasmu`.
5192217631581239183807531959944959 5192217631581239183807531959944959 5192217631581239183807531959944959 5192217631581239183807531959944959

runtimes before September

Because when I used older versions of the four runtimes from before September to run it, I encountered the situation shown in the figure below. I don't think this is caused by the min and max instructions, but rather by some other bug.

[wenyongh]

Hi, yes, I checked wasmtime-15.0.0 which was released in 2023-11-20., it reports "out of bounds memory access", but in the recent dev release, it doesn't throw exception. Not sure why.

[XinyuShe]

https://github.com/bytecodealliance/wasmtime/issues/7558#issue-2001694541 I reported a bug to wasmtime before, and they fixed it. I'm not sure if this is related to the absence of errors in the dev version.

I haven't come across any issues with Wasmer yet, and I think Wasmer is probably correct.

[XinyuShe]

@wenyongh Have you found the reason of this issue?

[wenyongh]

@XinyuShe I found that the outs of f32x4.max are different:

  (func $3 (result v128 v128 v128 v128)
    (local $0 v128)
    v128.const i32x4 0xbfe4b646 0xee2ae7a5 0x49ff9c4c 0x10fd4f0b
    local.set $0
    nop
    local.get $0
    i32x4.trunc_sat_f64x2_u_zero
    local.set $0
    local.get $0
    i32.const 756
    i16x8.replace_lane 0
    local.get $0
    f32x4.gt             => the result is `0xffffffff 0x00000000 0x00000000 0x00000000`
    v128.const i32x4 0xaad2899f 0x11c60963 0x34076b3e 0x18b611a6
    f32x4.max          => for wamr and wasmedge, the output is `0xffffffff 0x11c60963 0x34076b3e 0x18b611a6`
                        for wasmtime and wasmer, the output is `0xffc00000 0x11c60963 0x34076b3e 0x18b611a6`

And for wamr and wasmedge, it eventually causes the below opcode to throw OOB exception:

      block $block
      local.get $0
      i32x4.extract_lane 0
      v128.load32x2_u offset=6522 align=1       => OOB was thrown for wamr and wasmedge
      local.tee $0
      local.get $0
      i32x4.extend_high_i16x8_s

I think it is also same as the issue of NaN normalization, for wasmtime and wasmer, 0xffffffff is converted into 0xffc00000, or -nan.