WasmEdge

WasmEdge copied to clipboard

Summary

I generated a wasm code with an exported function called "main" and found that its behavior is different when using different runtimes. The wasm code is generated randomly, so there's no related source code.

I also try to find out why it happened and find that the implementation of instructions 'f64x2.mul', 'f64x2.add', 'f32x4.mul', 'f32x4.add' may have bugs because the stack data resulting from the execution of these instructions in WASMEDGE differs from that in other wasm runtimes, and I record the details in Expected State part.

The wasm file for each bug instruction:

f64x2.mul

filea154963.zip

f64x2.add

filea201519.zip

f32x4.mul

filea228042.zip

f32x4.add

filea118365.zip

Simplified File

Among the four instructions, the bugs in the two multiplication instructions are likely to be the same, and the bugs in the two addition instructions should also be identical.

MUL

simd1.zip We simplified the filea154963.wasm file containing f64x2.mul and got simd1.wasm; the execution results are shown in the figure above.

ADD

simd2.zip We also simplified the filea118365.wasm file containing f32x4.add and got simd2.wasm; the execution results are shown in the figure above.

Current State

Here is the output of WasmEdge, Wasmtime and Wasmer for the instructions:

f64x2.mul

==============================================================
filea154963.wasm
-----------------wasmedge-----------------
Executed: wasmedge --reactor filea154963.wasm main
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
-----------------wasmtime-----------------
Executed: wasmtime run --invoke main filea154963.wasm
warning: using `--invoke` with a function that returns values is experimental and may break in the future
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
root@4252f5ec38df:/home/sxy/exp/0_Issue_files# wasmer run filea154963.wasm -i main
316968409489397640197182485818085862287 316968409489397640197182485818085862287 316968409489397640197182485818085862287 316968409489397640197182485818085862287 316968409489397640197182485818085862287 316968409489397640197182485818085862287 316968409489397640197182485818085862287 316968409489397640197182485818085862287 316968409489397640197182485818085862287

f64x2.add

==============================================================
filea201519.wasm
-----------------wamr-----------------
Executed: wamrc -o filea201519.wasm.aot filea201519.wasm
Executed: iwasm --heap-size=0 -f main filea201519.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 filea201519.wasm.aot was generated.
<0xffffff00ffff0000 0x7ff8000000000000>:v128,<0xffffff00ffff0000 0x7ff8000000000000>:v128,<0xffffff00ffff0000 0x7ff8000000000000>:v128,<0xffffff00ffff0000 0x7ff8000000000000>:v128,<0xffffff00ffff0000 0x7ff8000000000000>:v128,<0xffffff00ffff0000 0x7ff8000000000000>:v128,<0xffffff00ffff0000 0x7ff8000000000000>:v128
-----------------wasmedge-----------------
Executed: wasmedge --reactor filea201519.wasm main
340240828546070184860793106435332374528
340240828546070184860793106435332374528
340240828546070184860793106435332374528
340240828546070184860793106435332374528
340240828546070184860793106435332374528
340240828546070184860793106435332374528
340240828546070184860793106435332374528
-----------------wasmtime-----------------
Executed: wasmtime run --invoke main filea201519.wasm
warning: using `--invoke` with a function that returns values is experimental and may break in the future
340240828546070184860793106439627276288
340240828546070184860793106439627276288
340240828546070184860793106439627276288
340240828546070184860793106439627276288
340240828546070184860793106439627276288
340240828546070184860793106439627276288
340240828546070184860793106439627276288

>>> x=340240828546070184860793106435332374528
>>> print(hex(x))
0xfff8000000000000ffffff0000000000
>>> x=340240828546070184860793106439627276288
>>> print(hex(x))
0xfff8000000000000ffffff00ffff0000

f32x4.mul

==============================================================
filea228042.wasm
-----------------wamr-----------------
Executed: wamrc -o filea228042.wasm.aot filea228042.wasm
Executed: iwasm --heap-size=0 -f main filea228042.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 filea228042.wasm.aot was generated.
<0xffffffffffffffff 0xffffffffffffffff>:v128,<0xffffffffffffffff 0xffffffffffffffff>:v128,<0xffffffffffffffff 0xffffffffffffffff>:v128,<0xffffffffffffffff 0xffffffffffffffff>:v128,<0xffffffffffffffff 0xffffffffffffffff>:v128,<0xffffffffffffffff 0xffffffffffffffff>:v128,<0xffffffffffffffff 0xffffffffffffffff>:v128
-----------------wasmedge-----------------
Executed: wasmedge --reactor filea228042.wasm main
340282366920938463463374607431768211455
340282366920938463463374607431768211455
340282366920938463463374607431768211455
340282366920938463463374607431768211455
340282366920938463463374607431768211455
340282366920938463463374607431768211455
340282366920938463463374607431768211455
-----------------wasmtime-----------------
Executed: wasmtime run --invoke main filea228042.wasm
warning: using `--invoke` with a function that returns values is experimental and may break in the future
340277174624388209442114290244617568000
340277174624388209442114290244617568000
340277174624388209442114290244617568000
340277174624388209442114290244617568000
340277174624388209442114290244617568000
340277174624388209442114290244617568000
340277174624388209442114290244617568000

>>> x=340282366920938463463374607431768211455
>>> print(hex(x))
0xffffffffffffffffffffffffffffffff
>>> x=340277174624388209442114290244617568000
>>> print(hex(x))
0xffff000000ff00ffffffffffff00ff00

f32x4.add

==============================================================
filea118365.wasm
-----------------wamr-----------------
Executed: wamrc -o filea118365.wasm.aot filea118365.wasm
Executed: iwasm --heap-size=0 -f main filea118365.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 filea118365.wasm.aot was generated.
<0x0001f8da0007ffff 0x0007ffff0007ffff>:v128,<0x0001f8da0007ffff 0x0007ffff0007ffff>:v128,<0x0001f8da0007ffff 0x0007ffff0007ffff>:v128,<0x0001f8da0007ffff 0x0007ffff0007ffff>:v128,<0x0001f8da0007ffff 0x0007ffff0007ffff>:v128,<0x0001f8da0007ffff 0x0007ffff0007ffff>:v128,<0x0001f8da0007ffff 0x0007ffff0007ffff>:v128
-----------------wasmedge-----------------
Executed: wasmedge --reactor filea118365.wasm main
41538295649787494874634426941702143
41538295649787494874634426941702143
41538295649787494874634426941702143
41538295649787494874634426941702143
41538295649787494874634426941702143
41538295649787494874634426941702143
41538295649787494874634426941702143
-----------------wasmtime-----------------
Executed: wasmtime run --invoke main filea118365.wasm
warning: using `--invoke` with a function that returns values is experimental and may break in the future
41533304265877708111193073984733183
41533304265877708111193073984733183
41533304265877708111193073984733183
41533304265877708111193073984733183
41533304265877708111193073984733183
41533304265877708111193073984733183
41533304265877708111193073984733183

>>> x=41538295649787494874634426941702143
>>> print(hex(x))
0x7ffff0007ffff0001f8da0007ffff
>>> x=41533304265877708111193073984733183
>>> print(hex(x))
0x7ffc0000000000001f8da0007ffff

Expected State

In this part, I have included some screenshots of my analysis. For each instruction, there are two screenshots. The first one shows the stack information when the instruction is executed under different WebAssembly runtimes. The second one shows the position of the instruction after converting the wasm file to a wat file using wasm2wat.

f64x2.mul

filea154963.zip The stack data of this instruction:

I have analyzed it and I think the error may occurred at line 53 of its wat file

f64x2.add

filea201519.zip The stack data of this instruction:

I have analyzed it and I think the error may occurred at line 36 of its wat file

f32x4.mul

filea228042.zip The stack data of this instruction:

I have analyzed it and I think the error may occurred at line 76 of its wat file

f32x4.add

filea118365.zip The stack data of this instruction:

I have analyzed it and I think the error may occurred at line 22 of its wat file

Reproduction steps

Execute with different wasm runtimes will get the difference.

An example:
-----------------wamr-----------------
wamrc -o filea201519.wasm.aot filea201519.wasm
iwasm --heap-size=0 -f main filea201519.wasm.aot
-----------------wasmedge-----------------
wasmedge --reactor filea201519.wasm main
-----------------wasmtime-----------------
wasmtime run --invoke main filea201519.wasm
-----------------wasmer-----------------
wasmer run filea201519.wasm -i main

Screenshots

No response

Any logs you want to share for showing the specific issue

I record the details in Expected State part.

Components

CLI

WasmEdge Version or Commit you used

wasmedge version 0.13.4

Operating system information

Docker version 24.0.5, build ced0996; Ubuntu 22.04.3 LTS

Hardware Architecture

GNU/Linux 5.15.0-79-generic x86_64

Compiler flags and options

No response

f64x2.mul has no problem, below example shows it's behave normal

(module
  (type (;0;) (func (result v128)))
  (func (;0;) (type 0) (result v128)
    v128.const i32x4 0xcba8d4ca 0xfcb11f90 0xbcf36ba4 0x7432877d
    v128.const i32x4 0xfa11cee5 0xfab7ba00 0xcc0d9896 0x38f6818a
    f64x2.mul
  )
  (memory (;0;) i32 0)
  (export "main" (func 0))
)

1. wasmedge 145187335775622910031581557238211280896
2. wasmtime 145187335775622910031581557238211280896

Can you shrink examples? Inaccurate random conjecture will not help.

simd.zip

We simplified the filea154963.wasm file containing f64x2.mul and got simd.wasm; the execution results are shown in the figure above.

simd.zip We simplified the filea118365.wasm file containing f32x4.add and got simd.wasm; the execution results are shown in the figure above.

Among the four instructions, the bugs in the two multiplication instructions are likely to be the same, and the bugs in the two addition instructions should also be identical.

I believe so, they use same foundation in interpreter mode.

And please update the major content of the issue, so contributors will no need to track the whole thread.

Latest wasmedge seems done it without problem

➜ ./tools/wasmedge/wasmedge simd-mul.wasm 
340282366920937259259921195292478734080
➜ wasmtime simd-mul.wasm        
warning: using `--invoke` with a function that returns values is experimental and may break in the future
340282366920937259259921195292478734080
➜ ./tools/wasmedge/wasmedge simd-add.wasm       
340282366920938463463374325952496664574
➜ wasmtime simd-add.wasm        
warning: using `--invoke` with a function that returns values is experimental and may break in the future
340282366920938463463374325952496664574

I will then check 0.13.4, if I also cannot reproduce, then it may a platform certain bug.

➜  ./WasmEdge-0.13.4-Darwin/bin/wasmedge simd-add.wasm
340282366920938463463374325956791631870
➜  ./WasmEdge-0.13.4-Darwin/bin/wasmedge simd-mul.wasm 
340282366920938463463374607431768211455

There has bug in 0.13.4, but fixed in latest version, close as complete.

unsubscribeSent from your KarstenOn Nov 14, 2023, at 00:57, Lîm Tsú-thuàn @.***> wrote: ➜ ./WasmEdge-0.13.4-Darwin/bin/wasmedge simd-add.wasm 340282366920938463463374325956791631870 ➜ ./WasmEdge-0.13.4-Darwin/bin/wasmedge simd-mul.wasm 340282366920938463463374607431768211455

There has bug in 0.13.4, but fixed in latest version, close as complete.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

To my knowledge, my issue was opened at 1:32 AM GMT+8 on November 3rd, and the new version 0.13.5 was released at 8:48 PM GMT+8 on the same day. I am not sure if the issue is supposed to be closed once the bug is fixed? @dannypsnl

Issue will be open if still having thing todo, WasmEdge haven’t go into stable mode, which mean we won’t port bug fix back to older version. Therefore, I believe there has nothing to do.

I retested the binary above and found that the new version did not fix the related bugs.

@XinyuShe I think you can reopen this issue.

@dannypsnl

Note: need bisect to find which commit introduce the problem in 0.13.5.

https://github.com/WasmEdge/WasmEdge/blob/master/lib/executor/engine/engine.cpp

@XinyuShe Do you still remember the wasmtime version you using? I get some interesting result: The behavior of wasmtime is different from original report.

$ wasmtime run --invoke main filea154963.wasm 
warning: using `--invoke` with a function that returns values is experimental and may break in the future
340282366920938463463374327056303128575
340282366920938463463374327056303128575
340282366920938463463374327056303128575
340282366920938463463374327056303128575
340282366920938463463374327056303128575
340282366920938463463374327056303128575
340282366920938463463374327056303128575
340282366920938463463374327056303128575
340282366920938463463374327056303128575
$ wasmtime --version
wasmtime-cli 14.0.4
# and wasmtime-cli 15.0.1

wasmedge part

$ wasmedge filea154963.wasm main
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
340282366920937259259921195296773636095
$ wasmedge --version
wasmedge version 0.13.5

@dannypsnl I used wasmtime version 14.0.1 However, It's strange that I cannot reproduce your result no matter I use wasmtime version 14.0.4 or 15.0.1

root@4252f5ec38df:/a# ./wasmtime_15.0.1 run --invoke main filea154963.wasm 
warning: using `--invoke` with a function that returns values is experimental and may break in the future
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
root@4252f5ec38df:/a# ./wasmtime_14.0.4 run --invoke main filea154963.wasm 
warning: using `--invoke` with a function that returns values is experimental and may break in the future
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
root@4252f5ec38df:/a# wasmtime run --invoke main filea154963.wasm 
warning: using `--invoke` with a function that returns values is experimental and may break in the future
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
316968409489397640197182485818085862287
root@4252f5ec38df:/a# wasmtime --version
wasmtime-cli 14.0.1
root@4252f5ec38df:/a# ./wasmtime_15.0.1 --version
wasmtime-cli 15.0.1
root@4252f5ec38df:/a# ./wasmtime_14.0.4 --version
wasmtime-cli 14.0.4

Probably due to system difference, I use macOS 14.1.1

Comment: same issue in #2812, #2813, #2814, #2815, #2816, #2817, #2988

Tested with the latest Wasmtime, Wasmer, ans WasmEdge 0.14.0-rc.5.

• WasmEdge has the same result on MacOS arm64 and Ubuntu 20.04 x86_64.
• Wasmtime and Wasmer has the same result with WasmEdge on MacOS arm64.
• Wasmtime and Wasmer has the same result on Ubuntu 20.04 x86_64, but is different with MacOS arm64