Changes in trap.rs

f820750b - Fix double read/writes on stream/future handles (#12873)

Mon, 30 Mar 2026 14:54:50 +0000

Fix double read/writes on stream/future handles (#12873)* Fix double read/writes on stream/future handlesThis should result in a first-class trap, not a bug.* Fix CI List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

da093747 - Relax panics in async/futures to traps/errors (#12688)

Mon, 02 Mar 2026 21:26:40 +0000

Relax panics in async/futures to traps/errors (#12688)* Relax panics in async/futures to traps/errorsThis commit is an admittance that I don't believe we're going to getto a point where we are confident enough in the fuzzing ofcomponent-model-async such that we could confidently say we'reexercising the vast majority of possible panics. Development ofcomponent-model-async has shown a steady trickle of panics over thecourse of the development of the feature, and this trend has beenpersistent over time as well.An attempt was made in #12119 to add a fuzzer dedicated to async eventsbut that didn't actually find anything in development and it has misseda number of panics present before and discovered after its introduction.Overall I do not know how to improve the fuzzer to the point that itwould find pretty much all of the existing async-related panics overtime.To help address this concern of the `concurrent.rs` implementation thiscommit goes through and replaces things like `unwrap()`, `assert!`,`panic!`, and `unreachable!` with an error-producing form. The benefitof this is that a bug in the implementation is less likely to result ina panic and instead just results in a non-spec-compliant trap. Thedownside of doing this though is that it can become unclear what errorsare "first class traps", or expected to be guest reachable, and whichare expected to be bugs in Wasmtime. To help address this I've performeda few refactorings here as well.* Some traps previously present as error strings are now promoted to using `Trap::Foo` instead. This has some refactoring of the Rust/C side as well to make it easier to define new variants. Tests were additionally added for any trap messages that weren't previously tested as being reachable.* A new `bail_bug!` macro was added (internally) for Wasmtime. This is coupled with a concrete `WasmtimeBug` error type (exported as `wasmtime::WasmtimeBug`). The intention is that `bail!` continues to be "here's a string and I'm a bit too lazy to make a concrete error" while `bail_bug!` indicates "this is a bug in wasmtime please report this if you see it".The rough vision is that if an error condition is reached, and the systemis not broken in such a way that panicking is required, then `bail_bug!`can be used to indicate a bug in Wasmtime as opposed to panicking. Thisreduces the real-world impact of hitting these scenarios by downgrading aCVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not allpanics are able to be transitioned to this as some are load bearing froma safety perspective or similar (or indicate something equally broken),but the vast majority of cases are suitable for "return a trap, lockdown the store, and let destructors take care of everything else".This change additionally has resulted in API changes for `FutureReader`and `StreamReader`. For example creation of these types now returns a`Result` for when the `ResourceTable` is full, for example, instead ofpanicking.* Fix CI build* Translate `WasmtimeBug` to panics in debug mode* Review comments* Refactor some stream methods for fewer panics List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

b856261d - refactor recursive reentrance checks (#12349)

Wed, 14 Jan 2026 22:27:49 +0000

refactor recursive reentrance checks (#12349)* refactor recursive reentrance checksThis commit makes a few changes related to recursive reentrance checks, instancepoisoning, etc.:- Implements the more restrictive lift/lower rules described in https://github.com/WebAssembly/component-model/pull/589 such that a component instance may not lower a function lifted by one of its ancestors, nor vice-versa. Any such lower will result in a fused adapter which traps unconditionally, preventing guest-to-guest recursive reentrance without requiring data flow analysis. - Note that this required updating several WAST tests which were violating the new rule, including some in the `tests/component-model` Git submodule, which I've updated. - This is handled entirely in the `fact` module now; I've removed the `AlwaysTrap` case previously handled by `wasmtime-cranelift`.- Removes `FLAG_MAY_ENTER` from `InstanceFlags`. It is no longer needed for guest-to-guest calls due to the above, and for guest-to-host-to-guest calls we can rely on either `FLAG_NEEDS_POST_RETURN` for sync-lifted functions or the `GuestTask` call stack for async-lifted functions.- Adds a `StoreOpaque::trapped` field which is set when _any_ instance belonging to that store traps, at which point the entire store is considered poisoned, meaning no instance belonging to it may be entered. This prevents indeterminant concurrent task state left over from the trapping instance from leaking into other instances.Note that this does _not_ include code to push and pop `GuestTask` instances forguest-to-guest sync-to-sync calls, nor for host-to-guest calls using e.g. thesynchronous `Func::call` API, so certain intrinsics which expect a `GuestTask`to be present such as `backpressure.inc` will still fail in such cases. I'lladdress that in a later PR.Also note that I made a small change to `wasmtime-wit-bindgen`, adding a `Send`bound on the `T` type parameter for `store | async` functions. This allowed meto recursively call `{Typed}Func::call_concurrent` from inside a host function,and it doesn't have any downsides AFAICT.Fixes #12128* bless bindgen expansions* bless disas tests* address review feedback* sync `trap.h` with `trap_encoding.rs`...and add const assertions to `trap.rs` to help avoid future divergence. List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

dc029724 - Migrate C API to `wasmtime::error` (#12259)

Wed, 07 Jan 2026 21:26:03 +0000

Migrate C API to `wasmtime::error` (#12259) List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

23e27bad - c-api: new wasmtime_trap_new_code function (#10765)

Thu, 15 May 2025 05:56:59 +0000

c-api: new wasmtime_trap_new_code function (#10765)* c-api: new wasmtime_trap_new_code function* review comments* remove accidental include List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

ae84e6ed - Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)

Thu, 09 Jan 2025 21:05:55 +0000

Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)* Enable `unsafe-attr-outside-unsafe` 2024 edition lintThis commit enables the `unsafe-attr-outside-unsafe` lint in rustc usedin transitioning to the 2024 edition. This requires that the`#[no_mangle]` attribute is replaced in favor of `#[unsafe(no_mangle)]`.This mostly affects the C API of wasmtime and most of the changes hereare a simple search/replace.* Another attribute update* Fix command adapter build List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

b79a96a1 - Leverage Rust 1.79, 1.80 (#9498)

Tue, 22 Oct 2024 22:00:39 +0000

Leverage Rust 1.79, 1.80 (#9498)This commit is a follow-up to #9496 to leverage various APIs that theworkspace now has access to. For example most dependencies on the`once_cell` crate are now removed in favor of the types stabilized inthe standard library: `LazyLock` and `LazyCell`. One dependency remainsin the `wasmtime` crate due to the `get_or_try_init` not being stableyet.Some additional helper methods on raw pointer slices are also availablefor removing a few minor `unsafe` blocks. List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

6a7ef27b - Make `wasmtime::WasmCoreDump` serializable (#7078)

Mon, 25 Sep 2023 20:11:45 +0000

Make `wasmtime::WasmCoreDump` serializable (#7078)This commit makes it so that the library type for core dumps is serializableinto the standard binary format for core dumps.Additionally, this commit makes it so that we use the library type forgenerating core dumps in the CLI. We previously were using a one-offimplementation of core dump generation that only had backtrace information andno instances, modules, globals, or memories included. The library type has allthat information, so the core dumps produced by our CLI will both be morefeatureful and be generated by shared code paths going forward.Along the way, implementing all this required some new helper methods sprinkledthroughout `wasmtime` and `wasmtime-runtime`:* `wasmtime::Instance::module`: get the module that a `wasmtime::Instance` is an instance of. This is public, since it seems generally useful. This involved adding a new return value from `ModuleRegistry::register_module` that is an identifier that can be used to recover a reference to the registered module.* `wasmtime::Instance::all_{globals,memories}`: get the full global/memory index space. I made these `pub(crate)` out of caution. I don't think we want to commit to exposing non-exported things in the public API, even if we internally need them for debugging-related features like core dumps. These also needed corresponding methods inside `wasmtime-runtime`.* `wasmtime::{Global,Memory}::hash_key`: this was needed to work around the fact that each time you call `{Global,Memory}::from_wasmtime`, it creates a new entry in the `StoreData` and so you can get duplicates. But we need to key some hash maps on globals and memories when constructing core dumps, so we can't treat the underlying `Stored` as a hash key because it isn't stable across duplicate `StoreData` entries. So we have these new methods. They are only `pub(crate)`, are definitely implementation details, and aren't exposed in the public API.* `wasmtime::FrameInfo::module`: Each frame in a backtrace now keeps a handle to its associated module instead of just the name. This is publicly exposed because it seems generally useful. This means I also deprecated `wasmtime::FrameInfo::module_name` since you can now instead do `frame.module().name()` to get that exact same info. I updated callers inside the repo. List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

42e88c7b - Fix `OutOfFuel` trap code not represented in the C API. (#5230)

Thu, 10 Nov 2022 20:42:26 +0000

Fix `OutOfFuel` trap code not represented in the C API. (#5230)This commit adds the missing "out of fuel" trap code to the C API. Without this, calls to `wasmtime_trap_code` will trigger an unreachable panic on traps from running out of fuel. List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

5b6d5e78 - Merge pull request from GHSA-h84q-m8rr-3v9q

Thu, 10 Nov 2022 17:35:14 +0000

Merge pull request from GHSA-h84q-m8rr-3v9qThe Rust definition was previously performing a 4-byte write when the CAPI was declared as taking an 1-byte buffer. List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

b07b0676 - Update how exits are modeled in the C API (#5215)

Mon, 07 Nov 2022 17:35:49 +0000

Update how exits are modeled in the C API (#5215)Previously extracting an exit code was only possibly on a `wasm_trap_t` which will never successfully have an exit code on it, so the exit code extractor is moved over to `wasmtime_error_t`. Additionally extracting a wasm trace from a `wasmtime_error_t` is added since traces happen on both traps and errors now. List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

2afaac51 - Return `anyhow::Error` from host functions instead of `Trap`, redesign `Trap` (#5149)

Wed, 02 Nov 2022 16:29:31 +0000

Return `anyhow::Error` from host functions instead of `Trap`, redesign `Trap` (#5149)* Return `anyhow::Error` from host functions instead of `Trap` This commit refactors how errors are modeled when returned from host functions and additionally refactors how custom errors work with `Trap`. At a high level functions in Wasmtime that previously worked with `Result` now work with `Result` instead where the error is `anyhow::Error`. This includes functions such as: * Host-defined functions in a `Linker` * `TypedFunc::call` * Host-related callbacks like call hooks Errors are now modeled primarily as `anyhow::Error` throughout Wasmtime. This subsequently removes the need for `Trap` to have the ability to represent all host-defined errors as it previously did. Consequently the `From` implementations for any error into a `Trap` have been removed here and the only embedder-defined way to create a `Trap` is to use `Trap::new` with a custom string. After this commit the distinction between a `Trap` and a host error is the wasm backtrace that it contains. Previously all errors in host functions would flow through a `Trap` and get a wasm backtrace attached to them, but now this only happens if a `Trap` itself is created meaning that arbitrary host-defined errors flowing from a host import to the other side won't get backtraces attached. Some internals of Wasmtime itself were updated or preserved to use `Trap::new` to capture a backtrace where it seemed useful, such as when fuel runs out. The main motivation for this commit is that it now enables hosts to thread a concrete error type from a host function all the way through to where a wasm function was invoked. Previously this could not be done since the host error was wrapped in a `Trap` that didn't provide the ability to get at the internals. A consequence of this commit is that when a host error is returned that isn't a `Trap` we'll capture a backtrace and then won't have a `Trap` to attach it to. To avoid losing the contextual information this commit uses the `Error::context` method to attach the backtrace as contextual information to ensure that the backtrace is itself not lost. This is a breaking change for likely all users of Wasmtime, but it's hoped to be a relatively minor change to workaround. Most use cases can likely change `-> Result` to `-> Result` and otherwise explicit creation of a `Trap` is largely no longer necessary. * Fix some doc links * add some tests and make a backtrace type public (#55) * Trap: avoid a trailing newline in the Display impl which in turn ends up with three newlines between the end of the backtrace and the `Caused by` in the anyhow Debug impl * make BacktraceContext pub, and add tests showing downcasting behavior of anyhow::Error to traps or backtraces * Remove now-unnecesary `Trap` downcasts in `Linker::module` * Fix test output expectations * Remove `Trap::i32_exit` This commit removes special-handling in the `wasmtime::Trap` type for the i32 exit code required by WASI. This is now instead modeled as a specific `I32Exit` error type in the `wasmtime-wasi` crate which is returned by the `proc_exit` hostcall. Embedders which previously tested for i32 exits now downcast to the `I32Exit` value. * Remove the `Trap::new` constructor This commit removes the ability to create a trap with an arbitrary error message. The purpose of this commit is to continue the prior trend of leaning into the `anyhow::Error` type instead of trying to recreate it with `Trap`. A subsequent simplification to `Trap` after this commit is that `Trap` will simply be an `enum` of trap codes with no extra information. This commit is doubly-motivated by the desire to always use the new `BacktraceContext` type instead of sometimes using that and sometimes using `Trap`. Most of the changes here were around updating `Trap::new` calls to `bail!` calls instead. Tests which assert particular error messages additionally often needed to use the `:?` formatter instead of the `{}` formatter because the prior formats the whole `anyhow::Error` and the latter only formats the top-most error, which now contains the backtrace. * Merge `Trap` and `TrapCode` With prior refactorings there's no more need for `Trap` to be opaque or otherwise contain a backtrace. This commit parse down `Trap` to simply an `enum` which was the old `TrapCode`. All various tests and such were updated to handle this. The main consequence of this commit is that all errors have a `BacktraceContext` context attached to them. This unfortunately means that the backtrace is printed first before the error message or trap code, but given all the prior simplifications that seems worth it at this time. * Rename `BacktraceContext` to `WasmBacktrace` This feels like a better name given how this has turned out, and additionally this commit removes having both `WasmBacktrace` and `BacktraceContext`. * Soup up documentation for errors and traps * Fix build of the C API Co-authored-by: Pat Hickey List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

4d9e10da - Fix panics in the C API related to trap frames (#4196)

Tue, 31 May 2022 15:39:11 +0000

Fix panics in the C API related to trap frames (#4196)The `wasmtime-cpp` test suite uncovered an issue where asking for the frames of a trap would fail immediately after the trap was created. In addition to fixing this issue I've also updated the documentation of `Trap::frames` to indicate when it returns `None`. List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

bffce370 - make backtrace collection a Config field rather than a cargo feature (#4183)

Wed, 25 May 2022 19:25:50 +0000

make backtrace collection a Config field rather than a cargo feature (#4183)* sorta working in runtime * wasmtime-runtime: get rid of wasm-backtrace feature * wasmtime: factor to make backtraces recording optional. not configurable yet * get rid of wasm-backtrace features * trap tests: now a Trap optionally contains backtrace * eliminate wasm-backtrace feature * code review fixes * ci: no more wasm-backtrace feature * c_api: backtraces always enabled * config: unwind required by backtraces and ref types * plumbed * test that disabling backtraces works * code review comments * fuzzing generator: wasm_backtrace is a runtime config now * doc fix List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

f1225dfd - Add a compilation section to disable address maps (#3598)

Mon, 13 Dec 2021 19:48:05 +0000

Add a compilation section to disable address maps (#3598)* Add a compilation section to disable address maps This commit adds a new `Config::generate_address_map` compilation setting which is used to disable emission of the `.wasmtime.addrmap` section of compiled artifacts. This section is currently around the size of the entire `.text` section itself unfortunately and for size reasons may wish to be omitted. Functionality-wise all that is lost is knowing the precise wasm module offset address of a faulting instruction or in a backtrace of instructions. This also means that if the module has DWARF debugging information available with it Wasmtime isn't able to produce a filename and line number in the backtrace. This option remains enabled by default. This option may not be needed in the future with #3547 perhaps, but in the meantime it seems reasonable enough to support a configuration mode where the section is entirely omitted if the smallest module possible is desired. * Fix some CI issues * Update tests/all/traps.rs Co-authored-by: Nick Fitzgerald * Do less work in compilation for address maps But only when disabled Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

f3b80ece - c-api: add wasmtime_trap_code (#3086)

Thu, 15 Jul 2021 15:31:03 +0000

c-api: add wasmtime_trap_code (#3086)Eventually this should be added to the wasmtime-go binding, addressing https://github.com/bytecodealliance/wasmtime-go/issues/63. Added a snippet to examples/interrupt.c to verify that this works as expected in manual testing. Signed-off-by: Stephan Renatus List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

7a1b7cdf - Implement RFC 11: Redesigning Wasmtime's APIs (#2897)

Thu, 03 Jun 2021 14:10:53 +0000

Implement RFC 11: Redesigning Wasmtime's APIs (#2897)Implement Wasmtime's new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it's best to read the RFC thread and the PR thread. List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

cca558cd - Remove `HostRef` from the C API (#1926)

Fri, 26 Jun 2020 19:34:34 +0000

Remove `HostRef` from the C API (#1926)This commit removes `HostRef` from the C API which only served the purpose now of converting each type to a `wasm_ref_t*`. Our implementation, however, does not guarantee that you'll get the same `wasm_ref_t*` for each actual underlying item (e.g. if you put a func in a table and then get the func as an export and from the table then `same` will report `false`). Additionally the fate of `wasm_ref_t*` seems somewhat unclear at this point. The change here is to make the `same` and cast functions all abort saying they're unimplemented. (similar to the host info functions). If and when we get around to reimplementing these functions we can ensure they're implemented uniformly and work well for all intended use cases. List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs

e40c039e - wasmtime: Rip out incomplete/incorrect externref "host info" support

Thu, 25 Jun 2020 17:24:40 +0000

wasmtime: Rip out incomplete/incorrect externref "host info" supportBetter to be loud that we don't support attaching arbitrary host info to`externref`s than to limp along and pretend we do support it. Supporting itproperly won't reuse any of this code anyways. List of files: /wasmtime-44.0.1/crates/c-api/src/trap.rs