alexcrichton opened issue #10289:
First discovered in https://github.com/bytecodealliance/wasmtime-go/pull/241 which is one of the main users of MinGW builds (AFAIK Go doesn't have MSVC integration). I've bisected through Github Actions (couldn't do so locally) and discovered the following:
- Wasmtime is currently built with the github actions
windows-2022
runner which uses gcc 12.2.0 from MinGW/MSYS2/something.- When these precompiled artifacts are used in wasmtime-go in tests test can fail with exception 0xc0000028 which stands for
STATUS_BAD_STACK
(aka resurrection of https://github.com/bytecodealliance/wasmtime/issues/1967)- Bisection showed the following properties:
- The faulty PR is https://github.com/bytecodealliance/wasmtime/pull/9929 (which in retrospect isn't too surprising)
- If the "faulty PR" is built with
windows-2025
, which uses gcc 14.2, then the bug does not happen.So it looks like our workaround of
-D__USE_MINGW_SETJMP_NON_SEH
, used to fix another bug in MinGW gcc is perhaps triggering some other bug in MinGW which is seemingly fixed with more recent GCC versions.Overall I personally wish we could just drop this target and not worry about it, but I'm unaware of how to integrate with Go on Windows any other way...
alexcrichton closed issue #10289:
First discovered in https://github.com/bytecodealliance/wasmtime-go/pull/241 which is one of the main users of MinGW builds (AFAIK Go doesn't have MSVC integration). I've bisected through Github Actions (couldn't do so locally) and discovered the following:
- Wasmtime is currently built with the github actions
windows-2022
runner which uses gcc 12.2.0 from MinGW/MSYS2/something.- When these precompiled artifacts are used in wasmtime-go in tests test can fail with exception 0xc0000028 which stands for
STATUS_BAD_STACK
(aka resurrection of https://github.com/bytecodealliance/wasmtime/issues/1967)- Bisection showed the following properties:
- The faulty PR is https://github.com/bytecodealliance/wasmtime/pull/9929 (which in retrospect isn't too surprising)
- If the "faulty PR" is built with
windows-2025
, which uses gcc 14.2, then the bug does not happen.So it looks like our workaround of
-D__USE_MINGW_SETJMP_NON_SEH
, used to fix another bug in MinGW gcc is perhaps triggering some other bug in MinGW which is seemingly fixed with more recent GCC versions.Overall I personally wish we could just drop this target and not worry about it, but I'm unaware of how to integrate with Go on Windows any other way...
alexcrichton commented on issue #10289:
Seems addressed by #10290, so closing.
Last updated: Feb 28 2025 at 02:27 UTC