alexcrichton opened PR #11892 from alexcrichton:fix-go to bytecodealliance:main:
This commit fixes some fallout of #11592 where that PR resulted in Wasmtime no longer running within the context of the Go runtime (e.g.
wasmtime-go). The reasons for this are quite Windows-specific and I've attempted to document the situation invectored_exceptions.go. The basic TL;DR; is that by returning from a vectored exception handler (which #11592 introduced) we're now subjecting ourselves to "continue handlers" as well, and Go's continue handlers will abort the process for non-Go exceptions. Some logic is added here to try to bypass Go's continue handlers and get back to wasm.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
alexcrichton requested wasmtime-core-reviewers for a review on PR #11892.
alexcrichton requested fitzgen for a review on PR #11892.
alexcrichton commented on PR #11892:
I have, yet again as is the case with wasmtime-go and integrating on various platforms, lost an embarassingly large amount of time debugging this...
bjorn3 submitted PR review.
bjorn3 created PR review comment:
*list
alexcrichton updated PR #11892.
fitzgen submitted PR review:
Sounds like this one was super fun to track down!
fitzgen created PR review comment:
// // # Safety // // Invoked by Windows' vectored exception system; should // not be called by anyone else. unsafe extern "system" fn continue_handler(exception_info: &EXCEPTION_POINTERS) -> i32 { let context = &exception_info.ContextRecord;Perhaps? Yes, it doesn't really actually change anything about the safety here, but it does mean there is one less
unsafeblock to decide whether it merits a// SAFETY:comment...
fitzgen created PR review comment:
The title of this section suggests that this is an overview of how continue handlers work, and then it proceeds to be a discussion about working around how the go runtime (ab)uses them. I think this comment could be a little more clear if we explicitly had a few different sections:
- An explanation of how VEH and continue handlers work and are intended to be used.
- An explanation of how the go runtime (ab)uses the system, and how this doesn't play nice / compose with other runtimes that need to install handlers, like Wasmtime.
- A description of what we are doing to work around (2).
All that said, this comment was super helpful for understanding the issues involved. Thanks for writing this stuff up!
alexcrichton updated PR #11892.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Good point! I reorganized to make it flow better like you suggested, I think I was a bit too frustrated with all of this yesterday to write clearly...
alexcrichton has enabled auto merge for PR #11892.
alexcrichton merged PR #11892.
Last updated: Dec 06 2025 at 07:03 UTC