Changes in trap.rs

c8764ed0 - Limit the number of frames in backtrace collection (#12542)

Wed, 18 Feb 2026 15:49:55 +0000

Limit the number of frames in backtrace collection (#12542)* Limit the number of frames in backtrace collectionAdd `Config::wasm_backtrace_max_frames` option to limit the number offrames collected in backtraces and set the default at 20. This helpsprevent expensive work from very deep call stacks.Setting the value to 0 is the same as disabling backtraces and so thischange deprecates `Config::wasm_backtrace`.Addresses https://github.com/bytecodealliance/wasmtime/issues/5052* review comments* fix tests* formatting* fix stack overflow test* fix docs and fuzzing* configure backtraces when fuzzing List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

bc4582c3 - Forbid rustdoc warnings in CI (#12420)

Tue, 27 Jan 2026 03:47:35 +0000

Forbid rustdoc warnings in CI (#12420)* Forbid rustdoc warnings in CIThis commit corrects our handling of rustdoc flags in CI to ensure thatwarnings indeed fire. Additionally this changes our flags to pass`-Dwarnings` to ensure that we have warning-free doc builds when allfeatures are enabled at least.There were quite a lot of preexisting issues to fix, so thisadditionally goes through and fixes all the warnings that cropped up.* Update nightly toolchain againprtest:full* Update another nightly* Fix a warning in generated code List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

Wed, 07 Jan 2026 17:08:11 +0000

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`Instead of `anyhow::Error`.This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`module, updates the prelude to include these new error-handling types, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse the new error types instead of `anyhow`.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense* cargo fmt* Move `crate::error::Thing` to `crate::Thing` where it makes sense List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

99ecf728 - Debug: create private code memories per store when debugging is enabled. (#12051)

Wed, 03 Dec 2025 01:18:00 +0000

Debug: create private code memories per store when debugging is enabled. (#12051)* Debug: create private code memories per store when debugging is enabled.This will allow patching code to implement e.g. breakpoints. (That is,for now the copies are redundant, but soon they will not be.)This change follows the discussion [here] and offline to define a fewtypes that better encapsulate the distinction we want to enforce.Basically, there is almost never a bare `CodeMemory`; they are alwayswrapped in an `EngineCode` or `StoreCode`, the latter being a per-storeinstance of the former. Accessors are moved to the relevant place sothat, for example, one cannot get a pointer to a Wasm function's bodywithout being in the context of a `Store` where the containing modulehas been registered. The registry then returns a `ModuleWithCode` thatboxes up a `Module` reference and `StoreCode` together for cases wherewe need both the metadata from the module and the raw code to derivesomething.The only case where we return raw code pointers to the `EngineCode`directly have to do with Wasm-to-array trampolines: in some cases, e.g.`InstancePre` pre-creating data structures with references to hostfunctions, it breaks our expected performance characteristics to makethe function pointers store-specific. This is fine as long as theWasm-to-array trampolines never bake in direct calls to Wasm functions;the strong invariant is that Wasm functions never execute from`EngineCode` directly. Some parts of the component runtime would alsohave to be substantially refactored if we wanted to do away with thisexception.The per-`Store` module registry is substantially refactored in this PR.I got rid of the modules-without-code distinction (the case where amodule only has trampolines and no defined functions still works fine),and organized the BTreeMaps to key on start address rather than endaddress, which I find a little more intuitive (one then queries with thedual to the range -- 0-up-to-PC and last entry found).[here]: https://github.com/bytecodealliance/wasmtime/pull/12051#pullrequestreview-3493711812* Review feedback: do not assume a reasonable code alignment; error when it cannot be known* Review feedback: fail properly in profiler when we are cloning code* Fix guest-profiler C API.* Review feedback: make private-code representation impossible in non-debugging-support builds.* Add TODO comment referencing issue for cloning only .text.* clang-format* Review feedback: add back Component::image_range.* Review feedback: error on registering profiling metadata when debug is enabled.* rustfmt* Remove early bail on profiling-data registration when debugging is enabled: this always happens so we cannot error out. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

1806c265 - Lookup functions in the text section by `FuncKey` at runtime (#11630)

Mon, 15 Sep 2025 22:35:40 +0000

Lookup functions in the text section by `FuncKey` at runtime (#11630)This commit refactors our metadata, treating compiled functions homogeneouslyand removing the need to add new tables to places like `CompiledModuleInfo`whenever we add a new kind of function. This also simplifies the process ofconstructing the metadata for a final, linked compilation artifact. Finally, itpaves the way to doing gc-sections during our linking process (which would giveus smaller code sizes by removing functions that have been inlined into everycaller, for example) as we now allow holes in certain types of function indexspaces that were previously always densely populated.We have two kinds of index spaces:1. Mostly-dense index spaces, which take O(max_index) space and provide O(1)lookups.2. Sparse index spaces, which take O(num_members) space and provideO(log n) lookups.Most of our function index spaces are currently dense, but we can tweak that inthe future if necessary.Furthermore, code size of `.cwasm` binaries has shrunk very slightly with thisrefactoring. Consider `spidermonkey.wasm`'s compiled `.cwasm`:* Size before: 218756 `.wasmtime.info` section bytes, 20052632 total bytes* Size after: 213761 `.wasmtime.info` section bytes, 20047640 total bytesThat is a 2.28% reduction on the size of the `.wasmtime.info` section, or a0.025% reduction total.However, we previously did a single metadata lookup to get the location of botha Wasm function itself and its array-to-Wasm trampoline at the same time, and inthe new version of the code two lookups are performed. This is slightly slower,as shown in our call-indirect micro-benchmark that combines lazy tableinitialization (which delays looking up the function element's location untilruntime) with indirect-calling each table element exactly once (which defeatsthe amortization of that lookup). So this micro-benchmark is both synthetic andthe worst-case scenario for this commit's change: we are measuring, as much aswe can, *only* the force-initialization-of-a-lazy-funcref-table-slot path.Ultimately, I believe that the simplification is worth the regression in thismicro-benchmark.

call-indirect micro-benchmarks results

```call-indirect/same-callee/table-init-lazy/65536-calls time: [152.77 µs 154.92 µs 157.39 µs] thrpt: [416.40 Melem/s 423.04 Melem/s 428.99 Melem/s] change: time: [−13.749% −10.205% −6.2864%] (p = 0.00 < 0.05) thrpt: [+6.7081% +11.365% +15.941%] Performance has improved.Found 13 outliers among 100 measurements (13.00%) 8 (8.00%) high mild 5 (5.00%) high severecall-indirect/different-callees/table-init-lazy/65536-calls time: [4.3564 ms 4.4641 ms 4.5843 ms] thrpt: [14.296 Melem/s 14.681 Melem/s 15.044 Melem/s] change: time: [+38.134% +44.404% +50.927%] (p = 0.00 < 0.05) thrpt: [−33.743% −30.750% −27.606%] Performance has regressed.Found 5 outliers among 100 measurements (5.00%) 2 (2.00%) high mild 3 (3.00%) high severecall-indirect/same-callee/table-init-strict/65536-calls time: [144.91 µs 148.41 µs 152.02 µs] thrpt: [431.10 Melem/s 441.58 Melem/s 452.24 Melem/s] change: time: [−13.665% −10.470% −7.2626%] (p = 0.00 < 0.05) thrpt: [+7.8313% +11.694% +15.828%] Performance has improved.Found 4 outliers among 100 measurements (4.00%) 1 (1.00%) high mild 3 (3.00%) high severecall-indirect/different-callees/table-init-strict/65536-calls time: [195.18 µs 200.67 µs 206.49 µs] thrpt: [317.38 Melem/s 326.59 Melem/s 335.77 Melem/s] change: time: [−15.936% −11.568% −7.0835%] (p = 0.00 < 0.05) thrpt: [+7.6235% +13.081% +18.957%] Performance has improved.Found 5 outliers among 100 measurements (5.00%) 5 (5.00%) high mild```

List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

2d25f862 - WebAssembly exception-handling support. (#11326)

Thu, 21 Aug 2025 02:55:44 +0000

WebAssembly exception-handling support. (#11326)* WebAssembly exception-handling support.This PR introduces support for the [Wasm exception-handling proposal],which introduces a conventional try/catch mechanism to WebAssembly. ThePR supports modules that use `try_table` to register handlers for alexical scope; and provides `throw` and `throw_ref` that allocate (inthe first case) and throw exception objects.This PR builds on top of the work in #10510 for Cranelift-levelexception support, #10919 for an unwinder, and #11230 for exceptionobjects built on top of GC, in addition a bunch of smaller fix andenabling PRs around those.[Wasm exception-handling proposal]: https://github.com/WebAssembly/exception-handling/prtest:full* Permit UnwindToWasm to have unused fields in Pulley builds (for now).* Resolve miri-caught reborrowing issue.* Ignore exceptions tests in miri for now (Pulley not supported).* Use wasmtime_test on exceptions tests.* Get tests passing on pulley platforms* Add a check to `supports_host` for the generated test and assert failure also when that is false.* Remove `pulley_unsupported` test as it falls out of `#[wasmtime_test]`* Remove `exceptions_store` helper as it falls out of `#[wasmtime_test]`* Remove miri annotations as they fall out of `#[wasmtime_test]`* Remove dead import* Skip some unsupported tests entirely in `#[wasmtime_test]`If the selected compiler doesn't support the host at all then there's noneed to run it. Actually running it could misinterpret `CraneliftNative`as "run with pulley" otherwise, so avoid such false negatives.* Cranelift: dynamic contexts: account for outgoing-args area.---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

838ed2d0 - Enable `allow_attributes_without_reason` (#11195)

Mon, 07 Jul 2025 21:52:03 +0000

Enable `allow_attributes_without_reason` (#11195)* Enable `allow_attributes_without_reason`This commit enables the `clippy::allow_attributes_without_reason` forthe `wasmtime` crate which previously forcibly allowed it. The reasonthis was allowed was that when the workspace was first migrated theWasmtime crate had too many instances that I was willing to fix. I'venow come back around and tried to fix everything.In short: ideally delete `#[allow]`, otherwise use `#[expect]`,otherwise use `#[allow]`.prtest:full* Adjust some directives* Fix some warnings* Fix stack switching size tests on unix* Don't have a conditional `Drop` impl* Force `testing_freelist` method to be usedToo lazy to write `#[cfg]`, but not too lazy to write a test. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/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/wasmtime/src/runtime/trap.rs

58ad9115 - Update how traps are rendered (#10523)

Fri, 04 Apr 2025 18:00:01 +0000

Update how traps are rendered (#10523)* Add 2 more columns to the default address width.* Print newlines between inline symbols which accidentally weren't present. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

8385bea2 - Adjust hints about using `WASMTIME_BACKTRACE_DETAILS` (#10498)

Mon, 31 Mar 2025 22:21:59 +0000

Adjust hints about using `WASMTIME_BACKTRACE_DETAILS` (#10498)This commit updates some infrastructure to hint that`WASMTIME_BACKTRACE_DETAILS` can be used to show more detail inbacktraces. Notably this warning is suppressed if `feature = "std"` isturned off or if `feature = "addr2line"` is turned off since both arerequired. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

452086fb - Store stack maps in an ELF section (#10404)

Thu, 20 Mar 2025 19:46:14 +0000

Store stack maps in an ELF section (#10404)* Store stack maps in an ELF sectionThis commit moves the storage of stack maps from being embedded withinserde-encoded information to instead being stored in a separate ELFsection in the final executable. The motivation for this is to make thismore easily debuggable with a `wasmtime objdump` command in the futurebut this additionally should have the nice side effect of makingnon-stack-maps modules have smaller encoded information (no need toencode an empty list) and additionally make stack-maps-using-modulesfaster to decode (no serde decoding, it's already "decoded").This implements a scheme similar to the address map section wherethere's a "builder" for the section and then a separate half to decodethe section. The same basic encoding, a bit map, is used. This is likelygoing to make accessing stack maps slightly slower, but if that's anissue we can tweak the representation and align things and/or use`usize` or such.* Update crates/environ/src/compile/stack_maps.rsCo-authored-by: Andrew Brown * Review comments* More review comments* Fix MIRI test by enabling `unaligned` object feature---------Co-authored-by: Andrew Brown List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

07eeac40 - Implement custom stack unwinding for Pulley (#9758)

Fri, 06 Dec 2024 22:41:17 +0000

Implement custom stack unwinding for Pulley (#9758)* Implement custom stack unwinding for PulleyThe pulley calling convention may not match the native callingconvention, which is the case for s390x, so the unwinding that Wasmtimedoes needs to be parameterized over what's being unwound. This commitadds a new `Unwind` trait with various methods behind it that thebacktrace implementation is then updated to use.* Fix alignment check for 32-bit List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

70a37939 - Support executing Pulley in Wasmtime (#9744)

Fri, 06 Dec 2024 20:23:55 +0000

Support executing Pulley in Wasmtime (#9744)* Support executing Pulley in WasmtimeThis commit is the initial implementation of executing the Pulleyinterpreter from the `wasmtime` crate. This gives access to all of the`wasmtime` crate's runtime APIs backed by execution of bytecode inPulley. This builds on the previous PRs I've been making for support inPulley to culminate in testing on CI in this PR. This PR handles somefinal tidbits related to producing a runnable image that can beinterpreted by the `wasmtime` crate such as:* Pulley compilation artifacts are no longer marked as natively executable, just read-only.* Pulley compilation artifacts include wasm-to-array trampolines like normal platforms (removes a pulley special-case).* Dispatch of host calls from Pulley to the Wasmtime runtime are implemented.* Pulley's list of panicking wasm features is slimmed down as most are covered by "this lowering isn't supported" errors.* Execution of wasm code now has an `if` to see whether Pulley is enabled within a `Store` or not.* Traps and basic "unwinding" of the pulley stack are implemented (e.g. a "pulley version" of `setjmp` and `longjmp`, sort of)* Halting the interpreter has been refactored to help shrink the size of `ControlFlow` and handle metadata with each done state.Some minor refactorings are also included here and there along with afew fixes here and there necessary to get tests passing.The next major part of this commit is updates to our `wast` test suiteand executing all `*.wast` files. Pulley is now executed by default forall files as a new execution engine. This means that all platforms in CIwill start executing Pulley tests. At this time almost all tests areflagged as "expected to fail" but there are a small handful ofallow-listed tests which are expected to pass. This exact list willchange over time as CLIF lowerings are implemented and the interpreteris extended.Follow-up PRs will extend the testing strategy further such as:* Extending `#[wasmtime_test]` to include Pulley in addition to Winch.* Getting testing set up on CI for 32-bit platforms.prtest:full* Fix pulley fuzz build* Fix clippy lints* Shuffle around some `#[cfg]`'d code* Remove unused imports* Update feature sets testing MIRIEnable pulley for wasmtime/wasmtime-cli and also enable all features forwasmtime-environ* Round up pulley's page size to 64k* Skip pulley tests on s390x for now* Add a safety rail for matching a pulley target to the host* Fix more pulley tests on s390x* Review comments* Fix fuzz build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

9034e101 - Rely on `core::error::Error` (#9702)

Tue, 03 Dec 2024 18:27:28 +0000

Rely on `core::error::Error` (#9702)* Rely on `core::error::Error`With Wasmtime's new MSRV at 1.81 this means that `core::error::Error` isavailable which means that in `no_std` mode the `Error` trait can beused. This has been integrated into `anyhow::Error` already upstream andmeans that we can remove our own local hacks such as the `Err2Anyhow` trait.This commit removes the `Err2Anyhow` trait and all usage, going back toidiomatic Rust error propagation and conversion even in the `no_std`world. This should make code more portable by default and remove someweird idioms we had for supporting this.prtest:full* Add some trusted vets* Audit object crate update* Disable backtraces on CI List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

6c97d5e6 - Simplify some trap handling in `wasmtime` runtime (#9673)

Mon, 25 Nov 2024 19:00:01 +0000

Simplify some trap handling in `wasmtime` runtime (#9673)The `needs_backtrace` field on `TrapReason` is an old artifact of havingthe `wasmtime` and `wasmtime-runtime` crates split and there's no longerany need for that. This commit removes the field and directly queries itfrom the error as necessary when capturing backtraces. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

d3132c9d - Add a `signals-based-traps` Cargo compile-time feature (#9614)

Tue, 19 Nov 2024 19:21:36 +0000

Add a `signals-based-traps` Cargo compile-time feature (#9614)* Gate signal handlers behind a new Cargo featureThis commit adds a new on-by-default Cargo feature to the `wasmtime`crate named `signals-based-traps`. This is modeled after the`Config::signals_based_traps` configuration at runtime and can be usedto statically disable the use of signal handlers in Wasmtime. Thisnotably reduces the number of platform dependencies that Wasmtime hasand provides a mode of avoiding relying on signals altogether.This introduces a new `MallocMemory` which is a linear memory backed bythe system allocator. This new type of memory is enabled when virtualmemory guards are disabled and signals-based-traps are disabled. Thismeans that this new type of memory will be candidate for fuzzing forexample.prtest:full* Fix rebase conflict* Refactor `MmapVec` documentation and representation* Remove no-longer-needed `Arc`* Document it may be backed by `Vec` List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

0bce0968 - Warn against `clippy::cast_possible_truncation` in Wasmtime (#9209)

Fri, 06 Sep 2024 22:25:50 +0000

Warn against `clippy::cast_possible_truncation` in Wasmtime (#9209)* Warn against `clippy::cast_possible_truncation` in WasmtimeThis commit explicitly enables the `clippy::cast_possible_truncation`lint in Clippy for just the `wasmtime::runtime` module. This does notenable it for the entire workspace since it's a very noisy lint and ingeneral has a low signal value. For the domain that `wasmtime::runtime`is working in, however, this is a much more useful lint. We in generalwant to be very careful about casting between `usize`, `u32`, and `u64`and the purpose of this module-targeted lint is to help with just that.I was inspired to do this after reading over #9206 where especially whenrefactoring code and changing types I think it would be useful to havelocations flagged as "truncation may happen here" which previouslyweren't truncating.The failure mode for this lint is that panics might be introduced wheretruncation is explicitly intended. Most of the time though this isn'tactually desired so the more practical consequence of this lint is toprobably slow down wasmtime ever so slightly and bloat it ever soslightly by having a few more checks in a few places. This is likelybest addressed in a more comprehensive manner, however, rather thanspecifically for just this one case. This problem isn't unique to justcasts, but to many other forms of `.unwrap()` for example.* Fix some casts in tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

1512a954 - Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)

Fri, 14 Jun 2024 15:24:12 +0000

Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)* Add `anyhow` stuff to our internal `wasmtime` crate preludeWe use it basically everywhere and it is annoying to have to import.I also did an audit of existing `use` statements and removed the now-redundantones and replaced one-off imports with usage of the prelude, so that the preludeis available by default in more places.* Fix `cargo doc` List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs

81a89169 - Add support for `#![no_std]` to the `wasmtime` crate (#8533)

Sat, 04 May 2024 22:02:26 +0000

Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime's platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren't implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime's TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the "custom" platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can't be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely on the `profiling` feature.* Refactor conversion to `anyhow::Error` in `wasmtime-environ`Have a dedicated trait for consuming `self` in addition to a`Result`-friendly trait.* Gate `gimli` in Wasmtime on `addr2line`Cut down the dependency list if `addr2line` isn't enabled since thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime's `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest:full* Fix build on wasm* Fix windows build* Remove unused import* Fix Windows/Unix build without `std` feature* Fix some doc links* Remove unused import* Fix build of wasi-common in isolation* Fix no_std build on macos* Re-fix build* Fix standalone build of wasmtime-cli-flags* Resolve a merge conflict* Review comments* Remove unused import List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trap.rs