Exception 0xc000001d crash when hitting unreachable on Windows

[webmaster128]

Describe the bug

I’m currently trying to get full stack testing with Wasmer-2.3.0+Windows(x86_64)+singlepass to work. This works nicely except for one case: I execute an unrachable operation in Wasm¹. Now when I embed the CosmWasm Rust code into a shared .dll build and call into it from a Go application, I get an Exception 0xc000001d 0x0 0x0 0x7ff93069a9a0 crash in the Rust code execution.

Steps to reproduce

On Windows:

1. Clone https://github.com/CosmWasm/wasmvm and checkout this PR
2. Run make build-rust to rebuild internal/api/wasmvm.dll
3. Run make test to execute the Go tests which link wasmvm.dll

Expected behavior

All tests pass.

Actual behavior

I get the crash²:

Exception 0xc000001d 0x0 0x0 0x7ff93069a9a0
PC=0x7ff93069a9a0
signal arrived during external code execution

runtime.cgocall(0xaca2e0, 0xc001fcb6d0)
	C:/Program Files/Go/src/runtime/cgocall.go:158 +0x4a fp=0xc001fcb638 sp=0xc001fcb600 pc=0x894a6a
github.com/CosmWasm/wasmvm/internal/api._Cfunc_execute({0x26c6449c6b0}, {0x0, 0xc0000187e0, 0x20}, {0x0, 0xc001fc3320, 0x85}, {0x0, 0xc000010900, 0x3b}, ...)
	_cgo_gotypes.go:342 +0x6e fp=0xc001fcb6d0 sp=0xc001fcb638 pc=0xabda4e
github.com/CosmWasm/wasmvm/internal/api.Execute.func1({0xb43120?}, {0x0?, 0xc0000187e0?, 0xc001fcb950?}, {0xc9?, 0xc001fc3320?, 0xc00011c7e0?}, {0x0, 0xc000010900, 0x3b}, ...)
	[...more of my Go stack trace...]

Additional context

OS: Windows Server 2022 Datacenter Edition
CPU: Intel(R) Xeon(R) CPU @ 2.30GHz
Flags: 3dnow, abm, aes, apic, avx, avx2, bmi1, bmi2, clflush, cmov, cx16, cx8, de, dts, erms, f16c, fma, fpu, fxsr, ht, hypervisor, ia64, invpcid, lahf_lm, mca, mce, mmx, movbe, msr, mtrr, osxsave, pae, pat, pcid, pclmulqdq, pge, pni, popcnt, pse, pse36, rdrnd, sep, serial, smep, ss, sse, sse2, sse4_1, sse4_2, ssse3, tm, tsc, vme, x2apic, xsave
Wasmer: 2.3.0
Rust: 1.60.0 and 1.65.0 on x86_64-pc-windows-msvc and x86_64-pc-windows-gnu

I do not get this error if

• I run the same test on Linux or Mac
• I run any Wasm that does not hit unreachable
• I run a Rust binary directly instead of a shared library

Which leads me to believe this is somehow related to the trap handlers involved after the unreachable.

Footnotes

1. I tested two ways to hit unreachable. First I execute metered Wasm using the default metering middleware and run a CPU loop in Wasm. Second I used core::arch::wasm32::unreachable() directly and compile it to Wasm. ↩

2. Full crash output here: https://app.circleci.com/pipelines/github/CosmWasm/wasmvm/1103/workflows/d8f40c4e-d672-4b9b-a9f2-eef11b7fcdd4/jobs/5718 ↩

[ptitSeb]

As discussed on Slack, let's try to reproduce this on latest Wasmer 3.x first.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[theduke]

Not stale.

[theduke]

Closing this for now.

@webmaster128 , please re-open if this is still an issue.

[webmaster128]

Yeah, thanks. We gave up the Windows support due to multiple issues in the build system. So I don't know if this issue still exists right now.