wasm operand stack overflow exception and weird fstat.st_ctim

[zzjas]

Hi, we noticed two weird behaviors from iwasm. Test files are included in iwasm.zip

Updated iwasm2.zip to include Makefile and some required txt files. You can run make <test name>.wasm and then <runtime name> --dir=. wasm/<test name>.wasm to see the output. The Makefile requires export WASI_SDK_PATH=/the/path/to/your/wasi-sdk.

Versions

iwasm: git commit 5547924e28c589aee62210ef464833c659950328 OS: OS X 11.4 wasi-sdk: 12.0

iwasm were compiled by

cd wasm-micro-runtime/product-mini/platforms/darwin/build
cmake .. -DWAMR_BUILD_AOT=1 -DWAMR_BUILD_LIBC_WASI=1
make

C files were compiled to Wasm files using the clang in wasi-sdk without special flags.

Wasm files were run with iwasm using iwasm --dir=. NAME.wasm without special flags.

Exception: wasm operand stack overflow

07ab1db939975ab2.c is a randomly generated C program that makes a bunch of system calls. When we run it with iwasm, iwasm prints Exception: wasm operand stack overflowto stdout without doing anything. We also tried to run it with Wasmtime and Wasmer. The test runs and returns fine with both of them.

(The included log.c and log.h is for debugging. Removing them and all logging from the test does not affect the exception)

Wrong st_ctim from fstat

fstat_ct.c simply prints the st_ctim for a file. For the same file (unchanged while testing), we found that Wasmtime and Wasmer gives the same number but iwasm will give a different one.

[xujuntwt95329]

Hi, iwasm use a small operand stack size by default, you can use iwasm --stack-size=xxxxx to use a larger operand stack. For your case, --stack-size=32768 is suitable

As for the st_ctim, thanks for reporting this weird behavior. I found that iwasm, wasmtime, wasmer and native all gives different value on my platform (Ubuntu 20.04), it is strange. I think it may be related to the WASI library implementation, I'll check if there is a bug in the library later.

Thanks again.