Changes in memory_creator.rs

94740588 - Migrate the Wasmtime CLI to `wasmtime::error` (#12295)

Fri, 09 Jan 2026 19:15:48 +0000

Migrate the Wasmtime CLI to `wasmtime::error` (#12295)* Migrate wasmtime-cli to `wasmtime::error`* migrate benches to `wasmtime::error` as well* Remove new usage of anyhow that snuck in List of files: /wasmtime-44.0.1/tests/all/memory_creator.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/tests/all/memory_creator.rs

073aedab - Enable the `unsafe-op-in-unsafe-fn` lint (#10559)

Wed, 09 Apr 2025 21:06:59 +0000

Enable the `unsafe-op-in-unsafe-fn` lint (#10559)* Enable the `unsafe-op-in-unsafe-fn` lintThis commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for theentire workspace. This lint will be warn-by-default in the 2024 editionso this is intended to smooth the future migration to the new edition.Many `unsafe` blocks were added in places the lint warned about, withtwo major exceptions. The `wasmtime` and `wasmtime-c-api` crates simplyexpect this lint to fire and effectively disable the lint. They're toobig at this time to do through this PR. My hope is that one day in thefuture they'll be migrated, but more realistically that probably won'thappen so these crates just won't benefit from this lint.* Fix nostd fiber buildprtest:full* Fix build on Windows* Fix asan build List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

48f4621f - Run the full test suite on 32-bit platforms (#9837)

Wed, 15 Jan 2025 18:43:18 +0000

Run the full test suite on 32-bit platforms (#9837)* Run the full test suite on 32-bit platformsThis commit switches to running the full test suite in its entirety(`./ci/run-tests.sh`) on 32-bit platforms in CI in addition to 64-bitplatforms. This notably adds i686 and armv7 as architectures that aretested in CI.Lots of little fixes here and there were applied to a number of tests.Many tests just don't run on 32-bit platforms or a platform withoutCranelift support, and they've been annotated as such where necessary.Other tests were adjusted to run on all platforms a few minor bug fixesare here as well.prtest:full* Fix clippy warning* Get wasm code working by default on 32-bitDon't require the `pulley` feature opt-in on 32-bit platforms to getwasm code running.* Fix dead code warning* Fix build on armv7* Fix test assertion on armv7* Review comments* Update how tests are skipped* Change how Pulley is defaultedDefault to pulley in `build.rs` rather than in `Cargo.toml` to make iteasier to write down the condition and comment what's happening. Thismeans that the `pulley-interpreter` crate and pulley support inCranelift is always compiled in now and cannot be removed. This shouldhopefully be ok though as the `pulley-interpreter` crate is stillconditionally used (meaning it can get GC'd) and the code-size ofCranelift is not as important as the runtime itself.* pulley: Save/restore callee-save state on traps* Fewer clippy warnings about casts* Use wrapping_add in `g32_addr`, fixing arm test List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

81d7de0a - Remove the `MemoryStyle` enum (#9583)

Thu, 07 Nov 2024 21:32:39 +0000

Remove the `MemoryStyle` enum (#9583)* Remove the `MemoryStyle` enumThere are no more major users left, only a few minor pieces here andthere. This should complete the refactoring to delete the "static" and"dynamic" terminology from Wasmtime and all we're left with are linearmemories with a few knobs in `Tunables`.* Fix test compile List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

f50d8d93 - Refactor the internals of `vm::Memory` to simplify the `RuntimeLinearMemory` trait (#9577)

Thu, 07 Nov 2024 19:02:58 +0000

Refactor the internals of `vm::Memory` to simplify the `RuntimeLinearMemory` trait (#9577)* Refactor internals of `vm::Memory`Instead of storing just a trait object store instead an `enum` between"local" memory and shared memory. This helps remove redundant traitimpls on shared memories, removes the need for `dyn Any`, and removesthe possibility of wrapping a shared memory as a shared memory. This isadditionally intended to make it a bit easier to see what's nested whereand reduce some layers of indirection.* Start implementing a `LocalMemory` abstractionThis is intended to be a non-shared implementation of a linear memorywith various bits and pieces tracking state. The end goal is to simplifythe `RuntimeLinearMemory` trait to its bare bones necessary tofaithfully implement wasm linear memory.* Move `vmmemory` to `LocalMemory`* Move CoW/max limits into `LocalMemory`Further simplify `RuntimeLinearMemory` by moving these responsibilitiesup a layer into the `LocalMemory` structure.* Simplify `memory_may_move` handling in `LocalMemory`No need to plumb it through all the traits any more. Now it's possibleto only have it handled in `LocalMemory` and other pieces don't have toworry about it.* Move `wasm_accessible` into `LocalMemory`Further simplify custom traits and mmap/static memory by moving moreresponsibility into `LocalMemory`.* Improve documentation of memories* Fix some CI failures* Handle more CI failures* More fixes for CI* Update crates/wasmtime/src/runtime/vm/memory.rsCo-authored-by: Nick Fitzgerald ---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

7a28a5b9 - Remove static/dynamic memories from public docs (#9545)

Tue, 05 Nov 2024 01:05:58 +0000

Remove static/dynamic memories from public docs (#9545)* Remove static/dynamic memories from public docsThis commit removes the terminology of "static" and "dynamic" memoriesfrom the public-facing documentation of Wasmtime, notably on the`Config` structure and its various configuration settings. The goal ofthis commit is in the same vein as #9543 which is to simplify the memorysettings of Wasmtime for users in this case.This change doesn't actually have any code changes beyond renames (andhandling now-deprecated CLI options). The goal of this commit is tobasically rewrite how we document the effect of various settings ofWasmtime. Notably:* `Config::static_memory_maximum_size` is now `memory_reservation`.* `Config::static_memory_forced` is now `memory_reservation_is_maximum`.* `Config::dynamic_memory_reserved_for_growth` is now `memory_reservation_for_growth`.Documentation for all of these options has been rewritten and updated totake into account the removal of "dynamic" and "static" terminology.Additionally more words have been written about the various effects ofeach setting and how things related to wasm features such as index typesizes and custom page sizes.The rewritten documentation is intended to basically already match whatWasmtime does today. I believe that all of these settings are useful inone form or another so none have been dropped but the updateddocumentation is intended to help simplify the mental model for howthey're processed internally and how they affect allocations and such.* Fix how the setting is flipped* Review comments List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

48d5338b - Merge static/dynamic guard size options (#9528)

Fri, 01 Nov 2024 17:21:11 +0000

Merge static/dynamic guard size options (#9528)* Merge static/dynamic guard size optionsThis commit is the first of what will likely be a few to refactor thememory-related configuration options in Wasmtime. The end goal of theserefactorings is to fix some preexisting issues and additionally make theconfiguration easier to understand for both users and implementorsalike. First on the chopping block here is to merge the`dynamic_memory_guard_size` and `static_memory_guard_size` options intoone option. AFAIK there's not a strong reason to have separateconfiguration options for these so it's hopefully simpler to have asingle `memory_guard_size` option which applies to all linear memoriesequally.I'll note that the old CLI options are preserved but are documented asdeprecated. We don't currently warn on using "deprecated options" so fornow the old options are just documented as deprecated and are otherwisesilently accepted.* Fix compilation of C API* Fix build of fuzzers List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

46098121 - style: simplify string formatting (#9047)

Wed, 31 Jul 2024 14:45:20 +0000

style: simplify string formatting (#9047)* style: simplify string formatting* fix: formatting in `benches/call.rs` List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

bdd78422 - Wasmtime: Implement the custom-page-sizes proposal (#8763)

Wed, 12 Jun 2024 21:46:42 +0000

Wasmtime: Implement the custom-page-sizes proposal (#8763)* Wasmtime: Implement the custom-page-sizes proposalThis commit adds support for the custom-page-sizes proposal to Wasmtime:https://github.com/WebAssembly/custom-page-sizesI've migrated, fixed some bugs within, and extended the `*.wast` tests for thisproposal from the `wasm-tools` repository. I intend to upstream them into theproposal shortly.There is a new `wasmtime::Config::wasm_custom_page_sizes_proposal` method toenable or disable the proposal. It is disabled by default.Our fuzzing config has been updated to turn this feature on/off as dictated bythe arbitrary input given to us from the fuzzer.Additionally, there were getting to be so many constructors for`wasmtime::MemoryType` that I added a builder rather than add yet anotherconstructor.In general, we store the `log2(page_size)` rather than the page sizedirectly. This helps cut down on invalid states and properties we need toassert.I've also intentionally written this code such that supporting any power of twopage size (rather than just the exact values `1` and `65536` that are currentlyvalid) will essentially just involve updating `wasmparser`'s validation andremoving some debug asserts in Wasmtime.* Update error string expectation* Remove debug logging* Use a right shift instead of a division* fix error message expectation again* remove page size from VMMemoryDefinition* fix size of VMMemoryDefinition again* Only dynamically check for `-1` sentinel for 1-byte page sizes* Import functions that are used a few times* Better handle overflows when rounding up to the host page sizePropagate errors instead of returning a value that is not actually a rounded upversion of the input.Delay rounding up various config sizes until runtime instead of eagerly doing itat config time (which isn't even guaranteed to work, so we already had to have abackup plan to round up at runtime, since we might be cross-compiling wasm ornot have the runtime feature enabled).* Fix some anyhow and nostd errors* Add missing rounding up to host page size at runtime* Add validate feature to wasmparser dep* Add some new rounding in a few places, due to no longer rounding in config methods* Avoid actually trying to allocate the whole address space in the `massive_64_bit_still_limited` testThe point of the test is to ensure that we hit the limiter, so just cancel theallocation from the limiter, and otherwise avoid MIRI attempting to allocate abunch of memory after we hit the limiter.* prtest:full* Revert "Avoid actually trying to allocate the whole address space in the `massive_64_bit_still_limited` test"This reverts commit ccfa34a78dd3d53e49a6158ca03077d42ce8bcd7.* miri: don't attempt to allocate more than 4GiB of memoryIt seems that rather than returning a null pointer from `std::alloc::alloc`,miri will sometimes choose to simply crash the whole program.* remove duplicate prelude import after rebasing List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

7313a979 - Change `MemoryStyle::Static` to store bytes, not pages (#8608)

Mon, 13 May 2024 21:10:17 +0000

Change `MemoryStyle::Static` to store bytes, not pages (#8608)* Change `MemoryStyle::Static` to store bytes, not pagesThis commit is inspired by me looking at some configuration in thepooling allocator and noticing that configuration of wasm pages vs bytesof linear memory is somewhat inconsistent in `Config`. In the end I'dlike to remove or update the `memory_pages` configuration in the poolingallocator to being bytes of linear memory instead to be more consistentwith `Config` (and additionally anticipate the custom-page-sizeswasm proposal where terms-of-pages will become ambiguous). The firststep in this change is to update one of the lowest layered usages ofpages, the `MemoryStyle::Static` configuration.Note that this is not a trivial conversion because the purpose ofcarrying around pages instead of bytes is that bytes may overflow whereoverflow-with-pages typically happens during validation. This means thatextra care is taken to handle errors related to overflow to ensure thateverything is still reported at the same time.* Update crates/wasmtime/src/runtime/vm/instance/allocator/pooling/memory_pool.rsCo-authored-by: Nick Fitzgerald * Fix tests* Really fix tests---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

9ce3ffe1 - Update some CI dependencies (#7983)

Thu, 22 Feb 2024 23:54:03 +0000

Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

f7d16d81 - clarify custom memory needs to be zero filled (#7565)

Tue, 21 Nov 2023 05:26:12 +0000

clarify custom memory needs to be zero filled (#7565)Signed-off-by: Tyler Rockwood List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

5856590f - Configure workspace lints, enable running some Clippy lints on CI (#7561)

Mon, 20 Nov 2023 23:23:41 +0000

Configure workspace lints, enable running some Clippy lints on CI (#7561)* Configure Rust lints at the workspace levelThis commit adds necessary configuration knobs to have lints configuredat the workspace level in Wasmtime rather than the crate level. Thisuses a feature of Cargo first released with 1.74.0 (last week) of the`[workspace.lints]` table. This should help create a more consistent setof lints applied across all crates in our workspace in addition topossibly running select clippy lints on CI as well.* Move `unused_extern_crates` to the workspace levelThis commit configures a `deny` lint level for the`unused_extern_crates` lint to the workspace level rather than theprevious configuration at the individual crate level.* Move `trivial_numeric_casts` to workspace level* Change workspace lint levels to `warn`CI will ensure that these don't get checked into the codebase andotherwise provide fewer speed bumps for in-process development.* Move `unstable_features` lint to workspace level* Move `unused_import_braces` lint to workspace level* Start running Clippy on CIThis commit configures our CI to run `cargo clippy --workspace` for allmerged PRs. Historically this hasn't been all the feasible due to theamount of configuration required to control the number of warnings onCI, but with Cargo's new `[lint]` table it's possible to have aone-liner to silence all lints from Clippy by default. This commit bydefault sets the `all` lint in Clippy to `allow` to by-default disablewarnings from Clippy. The goal of this PR is to enable selective accessto Clippy lints for Wasmtime on CI.* Selectively enable `clippy::cast_sign_loss`This would have fixed #7558 so try to head off future issues with thatby warning against this situation in a few crates. This lint is stillquite noisy though for Cranelift for example so it's not worthwhile atthis time to enable it for the whole workspace.* Fix CI errorprtest:full List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

c0bb341d - Run some tests in MIRI on CI (#6332)

Wed, 03 May 2023 21:02:33 +0000

Run some tests in MIRI on CI (#6332)* Run some tests in MIRI on CIThis commit is an implementation of getting at least chunks of Wasmtimeto run in MIRI on CI. The full test suite is not possible to run in MIRIbecause MIRI cannot run Cranelift-produced code at runtime (aka itdoesn't support JITs). Running MIRI, however, is still quite valuable ifwe can manage it because it would have trivially detectedGHSA-ch89-5g45-qwc7, our most recent security advisory. The goal of thisPR is to select a subset of the test suite to execute in CI under MIRIand boost our confidence in the copious amount of `unsafe` code inWasmtime's runtime.Under MIRI's default settings, which is to use the [StackedBorrows][stacked] model, much of the code in `Instance` and `VMContext`is considered invalid. Under the optional [Tree Borrows][tree] model,however, this same code is accepted. After some [extremely helpfuldiscussion][discuss] on the Rust Zulip my current conclusion is thatwhat we're doing is not fundamentally un-sound but we need to model itin a different way. This PR, however, uses the Tree Borrows model forMIRI to get something onto CI sooner rather than later, and I hope tofollow this up with something that passed Stacked Borrows. Additionallythat'll hopefully make this diff smaller and easier to digest.Given all that, the end result of this PR is to get 131 separate unittests executing on CI. These unit tests largely exercise the embeddingAPI where wasm function compilation is not involved. Some tests compilewasm functions but don't run them, but compiling wasm through Craneliftin MIRI is so slow that it doesn't seem worth it at this time. This doesmean that there's a pretty big hole in MIRI's test coverage, but that'sto be expected as we're a JIT compiler after all.To get tests working in MIRI this PR uses a number of strategies:* When platform-specific code is involved there's now `#[cfg(miri)]` for MIRI's version. For example there's a custom-built "mmap" just for MIRI now. Many of these are simple noops, some are `unimplemented!()` as they shouldn't be reached, and some are slightly nontrivial implementations such as mmaps and trap handling (for native-to-native function calls).* Many test modules are simply excluded via `#![cfg(not(miri))]` at the top of the file. This excludes the entire module's worth of tests from MIRI. Other modules have `#[cfg_attr(miri, ignore)]` annotations to ignore tests by default on MIRI. The latter form is used in modules where some tests work and some don't. This means that all future test additions will need to be effectively annotated whether they work in MIRI or not. My hope though is that there's enough precedent in the test suite of what to do to not cause too much burden.* A number of locations are fixed with respect to MIRI's analysis. For example `ComponentInstance`, the component equivalent of `wasmtime_runtime::Instance`, was actually left out from the fix for the CVE by accident. MIRI dutifully highlighted the issues here and I've fixed them locally. Some locations fixed for MIRI are changed to something that looks similar but is subtly different. For example retaining items in a `Store` is now done with a Wasmtime-specific `StoreBox` type. This is because, with MIRI's analyses, moving a `Box` invalidates all pointers derived from this `Box`. We don't want these semantics, so we effectively have a custom `Box` to suit our needs in this regard.* Some default configuration is different under MIRI. For example most linear memories are dynamic with no guards and no space reserved for growth. Settings such as parallel compilation are disabled. These are applied to make MIRI "work by default" in more places ideally. Some tests which perform N iterations of something perform fewer iterations on MIRI to not take quite so long.This PR is not intended to be a one-and-done-we-never-look-at-it-againkind of thing. Instead this is intended to lay the groundwork tocontinuously run MIRI in CI to catch any soundness issues. This feels,to me, overdue given the amount of `unsafe` code inside of Wasmtime. Myhope is that over time we can figure out how to run Wasm in MIRI butthat may take quite some time. Regardless this will be adding nontrivialmaintenance work to contributors to Wasmtime. MIRI will be run on CI formerges, MIRI will have test failures when everything else passes,MIRI's errors will need to be deciphered by those who have probablynever run MIRI before, things like that. Despite all this to me it seemsworth the cost at this time. Just getting this running caught twopossible soundness bugs in the component implementation that could havehad a real-world impact in the future![stacked]: https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md[tree]: https://perso.crans.org/vanille/treebor/[discuss]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Tree.20vs.20Stacked.20Borrows.20.26.20a.20debugging.20question* Update alignment comment List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

28371bfd - Validate faulting addresses are valid to fault on (#6028)

Fri, 17 Mar 2023 14:52:54 +0000

Validate faulting addresses are valid to fault on (#6028)* Validate faulting addresses are valid to fault onThis commit adds a defense-in-depth measure to Wasmtime which isintended to mitigate the impact of CVEs such as GHSA-ff4p-7xrq-q5r8.Currently Wasmtime will catch `SIGSEGV` signals for WebAssembly code solong as the instruction which faulted is an allow-listed instruction(aka has a trap code listed for it). With the recent security issue,however, the problem was that a wasm guest could exploit a compiler bugto access memory outside of its sandbox. If the access was successfulthere's no real way to detect that, but if the access was unsuccessfulthen Wasmtime would happily swallow the `SIGSEGV` and report a nominaltrap. To embedders, this might look like nothing is going awry.The new strategy implemented here in this commit is to attempt to bemore robust towards these sorts of failures. When a `SIGSEGV` is raisedthe faulting pc is recorded but additionally the address of theinaccessible location is also record. After the WebAssembly stack isunwound and control returns to Wasmtime which has access to a `Store`Wasmtime will now use this inaccessible faulting address to translate itto a wasm address. This process should be guaranteed to succeed asWebAssembly should only be able to access a well-defined region ofmemory for all linear memories in a `Store`.If no linear memory in a `Store` could contain the faulting address,then Wasmtime now prints a scary message and aborts the process. Thepurpose of this is to catch these sorts of bugs, make them very louderrors, and hopefully mitigate impact. This would continue to notmitigate the impact of a guest successfully loading data outside of itssandbox, but if a guest was doing a sort of probing strategy trying tofind valid addresses then any invalid access would turn into a processcrash which would immediately be noticed by embedders.While I was here I went ahead and additionally took a stab at #3120.Traps due to `SIGSEGV` will now report the size of linear memory and theaddress that was being accessed in addition to the bland "access out ofbounds" error. While this is still somewhat bland in the context of ahigh level source language it's hopefully at least a little bit moreactionable for some. I'll note though that this isn't a guaranteedcontextual message since only the default configuration for Wasmtimegenerates `SIGSEGV` on out-of-bounds memory accesses. Dynamicallybounds-checked configurations, for example, don't do this.Testing-wise I unfortunately am not aware of a great way to test this.The closet equivalent would be something like an `unsafe` method`Config::allow_wasm_sandbox_escape`. In lieu of adding tests, though, Ican confirm that during development the crashing messages works justfine as it took awhile on macOS to figure out where the faulting addresswas recorded in the exception information which meant I had lots ofinstances of recording an address of a trap not accessible from wasm.* Fix tests* Review comments* Fix compile after refactor* Fix compile on macOS* Fix trap test for s390xs390x rounds faulting addresses to 4k boundaries. List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

6d6bd0ea - Result alias for convienient use of anyhow::Error without depending on anyhow (#5853)

Fri, 24 Feb 2023 15:37:34 +0000

Result alias for convienient use of anyhow::Error without depending on anyhow (#5853)* Add a Result type alias* Refer to the type in top-level docs* Use this inside the documentation for the bindgen! macro* Fix tests* Address small PR feedback* Simply re-export anyhow types List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

fa36e86f - Update WASI to cap-std 0.25 and windows-sys. (#4302)

Thu, 23 Jun 2022 17:47:15 +0000

Update WASI to cap-std 0.25 and windows-sys. (#4302)This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

ea0cb971 - Update to rustix 0.26.2. (#3521)

Mon, 15 Nov 2021 18:21:13 +0000

Update to rustix 0.26.2. (#3521)This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras. List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs

e5ebef1b - Use `empty()` instead of `NONE` with rsix flags types.

Thu, 30 Sep 2021 15:14:13 +0000

Use `empty()` instead of `NONE` with rsix flags types.`empty()` is provided by all `bitflags` types, so it's more idiomaticthan having `NONE` values. List of files: /wasmtime-44.0.1/tests/all/memory_creator.rs