Wasmtime GitHub notifications bot (May 06 2026 at 22:06): Wasmtime GitHub notifications bot (May 06 2026 at 22:06):alexcrichton opened PR #13310 from alexcrichton:more-unwind-refactor to bytecodealliance:main:
This commit at a high level primarily addresses the test case added here. Specifically if a debug handler, on an exception event, takes the exception from the store then previously that would cause Wasmtime to abort the process. This bug is now fixed, and the fix is done by performing a refactor of the surrounding code that panicked.
The main change implemented here is to deduce what to do in the face of a wasm trap after a debug handler is invoked, not before. This is because a debug handler could remove the exception or even change the exception being thrown throughout its invocation. This means that we don't actually know what's going to happen until after the debug handler is invoked.
Upon moving this code around, however, I noticed that a lot of historical structure in
traphandlers.rswas at this point no longer necessary. Much of this commit is then trimming down the abstractions in this file and reorganization how exactly everything is handled. For example theBox<Trap>to hand over tocrate::trapis created much sooner in the "slow" path where a trap happens rather than the "hot function" where wasm is being invoked. Additionally the number of variants and storage in various enums were all trimmed down to basics to represent the smaller set of states that are now possible.Finally, this change additionally updates the debugger WIT world that Wasmtime exports by removing the difference between
caught-exception-thrownanduncaught-exception-thrown. Now instead there's justexceptionindicating that an exception is being thrown. Whether it's going to be caught depends on whether the debugger changes the exception or not. In the future if the distinction is necessary I figure we can add some more methods for inspecting the state.<!--
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
-->
Wasmtime GitHub notifications bot (May 06 2026 at 22:06):alexcrichton requested fitzgen for a review on PR #13310.
Wasmtime GitHub notifications bot (May 06 2026 at 22:06):alexcrichton requested wasmtime-core-reviewers for a review on PR #13310.
Wasmtime GitHub notifications bot (May 06 2026 at 22:12):alexcrichton edited PR #13310:
This commit at a high level primarily addresses the test case added here. Specifically if a debug handler, on an exception event, takes the exception from the store then previously that would cause Wasmtime to abort the process. This bug is now fixed, and the fix is done by performing a refactor of the surrounding code that panicked.
The main change implemented here is to deduce what to do in the face of a wasm trap after a debug handler is invoked, not before. This is because a debug handler could remove the exception or even change the exception being thrown throughout its invocation. This means that we don't actually know what's going to happen until after the debug handler is invoked.
Upon moving this code around, however, I noticed that a lot of historical structure in
traphandlers.rswas at this point no longer necessary. Much of this commit is then trimming down the abstractions in this file and reorganization how exactly everything is handled. For example theBox<Trap>to hand over tocrate::trapis created much sooner in the "slow" path where a trap happens rather than the "hot function" where wasm is being invoked. Additionally the number of variants and storage in various enums were all trimmed down to basics to represent the smaller set of states that are now possible.Finally, this change additionally updates the debugger WIT world that Wasmtime exports by removing the difference between
caught-exception-thrownanduncaught-exception-thrown. Now instead there's justexceptionindicating that an exception is being thrown. Whether it's going to be caught depends on whether the debugger changes the exception or not. In the future if the distinction is necessary I figure we can add some more methods for inspecting the state.Closes #13308
<!--
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
-->
Wasmtime GitHub notifications bot (May 07 2026 at 01:17):github-actions[bot] added the label wasmtime:api on PR #13310.
Wasmtime GitHub notifications bot (May 07 2026 at 06:14):alexcrichton commented on PR #13310:
This change turns out to additionally fix a heap corruption issue as well. Previously it was possible to change the exception being thrown in a debug handler, but the wasm catch wasn't updated, so it was possible to jump to a handler expecting one exception type when it actually caught another.
Wasmtime GitHub notifications bot (May 07 2026 at 20:05)::thumbs_up: fitzgen submitted PR review:
LGTM!
Wasmtime GitHub notifications bot (May 07 2026 at 20:06):alexcrichton added PR #13310 Refactor the internals of handling traps/unwinds to the merge queue.
Wasmtime GitHub notifications bot (May 07 2026 at 21:20):github-merge-queue[bot] removed PR #13310 Refactor the internals of handling traps/unwinds from the merge queue.
Wasmtime GitHub notifications bot (May 07 2026 at 22:07):alexcrichton updated PR #13310.
Wasmtime GitHub notifications bot (May 07 2026 at 22:08):alexcrichton has enabled auto merge for PR #13310.
Wasmtime GitHub notifications bot (May 07 2026 at 22:20):alexcrichton added PR #13310 Refactor the internals of handling traps/unwinds to the merge queue.
Wasmtime GitHub notifications bot (May 07 2026 at 22:44)::check: alexcrichton merged PR #13310.
Wasmtime GitHub notifications bot (May 07 2026 at 22:44):alexcrichton removed PR #13310 Refactor the internals of handling traps/unwinds from the merge queue.
Last updated: Jun 01 2026 at 09:49 UTC