No output but expected to have one while executing Wasm file

[luxinyi0105]

Describe the bug

While executing the given wasm file, we expected to output the calculated checksum, but in reality, there was no output.

Versions and Environment

Tools version: wasmi_cli 0.30.0 Operating system: Ubuntu 22.04.1 Architecture: x86_64

Steps to reproduce

TestCase.zip

$ wasmi_cli testcase_1.wasm

Expected behavior

$ wasmi_cli testcase_1.wasm
executing File("testcase_1.wasm")::_start() ...
checksum = DAFC642C

Actual behavior

$ wasmi_cli testcase_1.wasm
executing File("testcase_1.wasm")::_start() ...

Additional context

Actually, I don't know what the correct result of the test case should look like, either. So I used some other WebAssembly runtimes, such as wasmedge and wasm-micro-runtime(WAMR), to execute the same test case, they output the correct checksum result.

[Robbepop]

@luxinyi0105 Thank you for the bug report and sorry for taking so long to respond!

Currently the WASI implementation of wasmi is flagged as experimental. The reasons for this are:

• We are using an outdated WASI implementation of the BytecodeAlliance. Unfortunately we cannot use a more up-to-date version since the WASI project decided to strongly depend on the Wasmtime project.
• We chose to use an existing WASI implementation instead of implementing our own because it simply is less work to maintain. However, at the same time we also lack substantial tests for the WASM bindings we use.
• The whole WASI implementation for wasmi was contributed by @OLUWAMUYIWA in their spare free time for which I am extremely grateful. Yet, WASI is not important to my employer (Parity) and therefore there is no actual investment and a dependence on external contributors to improve the feature and support.

[Robbepop]

@luxinyi0105 Can you try out if this one now works as intended with the fully-optimized wasmi as with https://github.com/paritytech/wasmi/issues/750 and https://github.com/paritytech/wasmi/issues/751?

[luxinyi0105]

@luxinyi0105 Can you try out if this one now works as intended with the fully-optimized wasmi as with #750 and #751?

I followed your suggestion, but the execution result is not satisfactory. Executing the given wasm file with the fully optimized wasmi still do not output anything.

Actually, the given testcase simply mutated a wasm file, which was obtained by compiling the C program generated with Csmith using the Emscripten compiler (Emcc), and the mutation will make wasm module's in-memory shadow-stack pointer corrupted.

Some other WASM Runtimes, such as WasmEdge and WAMR, output checksum result checksum = DAFC642C while executing the same wasm file. It seems right, but witx spec says misaligned pointers ... shall trap, so in this sence, their results are not entirely correct.

Perhaps wasmi output nothing because it also detected problems related to misaligned pointers. But it seems that printing somethng like "Runtime Error" in the terminal is a better choice.

[Robbepop]

It seems right, but witx spec says misaligned pointers ... shall trap, so in this sence, their results are not entirely correct.

That's interesting since wasmi does not care if pointers accesses are unaligned. This is due to the fact that pointers in wasmi are actually just integer indices into some Vec-based buffer and no real pointers on the machine. However, it might be that Wasm mandates to be more protective against unaligned pointers and then wasmi would be not standards compliant. I have to check that.

Wild guess but it could be that the JIT based Wasm runtimes you tested silently align the pointers and therefore experience no problems during execution. wasmi on the other hand tries to work with the unaligned pointer and fails to make sense out of the Wasm (because it doesn't). And witx checks for actual alignment and properly fails.

[luxinyi0105]

@Robbepop Recently, I discovered an interesting testcase. Wasmi will output runtime error caused by misaligned pointer while executing this wasm file. This result is expected and the same as other runtime tools, such as wasmer and wasmtime. As mentioned before, other runtime tools like WasmEdge and WAMR will output checksum result. For the given wasm file, their output result is checksum = EE711B3B, but it seems that they do not follow witx spec.

I am not sure why Wasmi did not get similar result while executing previously submitted testcase in zip. Perhaps there are still some problems with the relevant components. The detail still needs your judgment. Thanks a lot.

[Robbepop]

This should be triaged with the WASI dependency updates implemented.

[Robbepop]

@luxinyi0105 I just re-ran the above Wasm test file on Wasmi v0.38.0 and it now outputs the same error as Wasmtime:

% time wasmi_cli 02-original.wasm
Error: failed during execution of _start: Pointer not aligned to 4: Region { start: 2045, len: 4 }
wasmi_cli 02-original.wasm  0.01s user 0.00s system 76% cpu 0.014 total

Wasmtime's output:

% time wasmtime 02-original.wasm
Error: failed to run main module `02-original.wasm`

Caused by:
    0: failed to invoke command default
    1: error while executing at wasm backtrace:
           0: 0x6b1a - <unknown>!<wasm function 23>
           1: 0x7130 - <unknown>!<wasm function 40>
           2: 0x7c6c - <unknown>!<wasm function 43>
           3: 0x73d0 - <unknown>!<wasm function 42>
           4: 0x7269 - <unknown>!<wasm function 41>
           5: 0x8099 - <unknown>!<wasm function 50>
           6: 0x6aa4 - <unknown>!<wasm function 22>
           7: 0x6520 - <unknown>!<wasm function 12>
           8: 0x5b8d - <unknown>!<wasm function 7>
           9: 0x6839 - <unknown>!<wasm function 16>
          10: 0x67b3 - <unknown>!<wasm function 15>
    2: Pointer not aligned to 4: Region { start: 2045, len: 4 }
wasmtime 02-original.wasm  0.04s user 0.02s system 188% cpu 0.033 total

I hereby consider this bug fixed and close this issue.