heads up - possible issues with gcc 13.1

[avih]

I've compiled wasm3 in w64dekvit (using standard cmake for windows, used with -G "MinGW Makefiles" to generate makefiles which use cmd.exe instead of sh because it doesn't quite work with busybox-w32 sh), and I'm noticing random errors while running wasm files with wasm3 compiled with w64devkit 1.19.0 (x86-64) but no issues with 1.18.0 (also 64), and also no issues with the same wasm file with other wasi runners, like wasmer and wasmtime.

So I'm suspecting either some issue with gcc 13.1 (w64dekvit 1.19) compared to 12.2 (w64dk 1.18), or, probably not unimaginable, some dodgy code in wasm3 which happens to work with gcc 12.2 but not 13.1. The compilation does have quite a few warnings, and the code does try to squeeze performance where possible, I think.

That's the only evidence I have so far, and I've not explored it further, so this is just a heads up.

I can provide the wasm3 binaries and test files if needed.

[skeeto]

Thank you for pointing this out, though I strongly suspect these are wasm3 bugs. The run-wasi-tests.py tests all pass with GCC 12.2 under w64devkit 1.18.0 using a default build. However, if I enable UBSan then 8 of 12 tests fail due to undefined behavior. (7 of 12 fail on Linux, so it's not just Windows.)

$ CFLAGS="-fsanitize=undefined -fsanitize-undefined-trap-on-error" cmake ..

There's signed overflow in at least two places. Under GCC 13.1 -O3, without UBSan, 5 tests fail, a subset of the 8 failing under UBSan — more evidence that it's related. All failures are access violations (code 0xC0000005). Under GCC 13.1 -O0, all tests pass, indicating it's happens only under optimization. On the other hand, -fwrapv makes no difference in the outcome, so it seems there's something more to it that UBSan doesn't catch.

The Python script helpfully outputs the test command, which you can copy-paste to run under GDB yourself and have a look. Unfortunately the undefined behavior is buried in several layers of macros (m3_exec.h) so it's really difficult to see what's going on.

The documentation indicates they fuzz under UBSan, so I'm surprised it's gone unnoticed. At least one of these bugs dates back to 2019. The last wasm3 release was 2 years ago and perhaps they haven't tested again since at least then?

[avih]

Thank you for the detailed reply.

CFLAGS="-fsanitize=undefined -fsanitize-undefined-trap-on-error" cmake ..

I tried this (at . rather than ..):

CFLAGS="-fsanitize=undefined -fsanitize-undefined-trap-on-error" cmake .
make -j12
./wasm3 myapp.wasm ...

and it fails the same. Is that supposed to print additional UBSan related messages if such issues are detected? I'm not seing any.

Under GCC 13.1 -O3, without UBSan, 5 tests fail, a subset of the 8 failing under UBSan — more evidence that it's related. All failures are access violations (code 0xC0000005)

That is interesting. First that tests fail (I don't have python setup to try this myself), and then the exit code. While running in busybox-w32 sh the random aborts are always with exit code 5. I'm guessing this is the same issue, with the exit code upper bits getting lost in translation.

I strongly suspect these are wasm3 bugs

In light of the above, yeah, sounds reasonable.

I don't intend to pursue the wasm3 issue further as I'm not really invested in it, but I might file a bug report with them and point here.

Thanks again for the time and analysis. (I'm leaving it for you to decide whether to close this issue, I'm fine with it getting closed).

[skeeto]

Is that supposed to print additional UBSan related messages if such issues are detected?

Since libubsan is not yet ported to Mingw-w64, no diagnostics. The "trap-on-error" option tells it to execute a trap instruction instead, which will break in the attached debugger, or otherwise crash (i.e. fail the test). If you choose to continue investigating, run it under GDB:

$ gdb --tui --args wasm3.exe myapp.wasm
(gdb) run

You'll want debug info enabled, too: -g or, better, -g3.

(I don't have python setup to try this myself)

My recommendation: Grab a "dot" WinPython release, about ~23MiB, which is just a self-extracting archive. If you have 7-zip, you can open it without running the self-extractor. Inside is a little CPython distribution which you can pluck out and run by itself. No fuss, no installation, much like w64devkit. Simply delete when no longer needed.

https://winpython.github.io/

(Warning: Windows 10 and later has an "app execution alias" for "python" that installs itself in front of your cmd.exe PATH. You will need to disable in order to access Python from a cmd.exe prompt.)

exit code upper bits getting lost in translation

I agree, that sounds likely.

[avih]

Grab a "dot" WinPython release

Nice. I'll try that. Thanks.