Changes in lib.rs

f3156fe0 - Update fibers to avoid no-return functions (#12928)

Wed, 01 Apr 2026 20:22:31 +0000

Update fibers to avoid no-return functions (#12928)* Update fibers to avoid no-return functionsThis commit is aimed at fixing the ASAN false positives in #12899.Initially the fix there was to invoke some `__asan_*` intrinsics, andI ended up finding a sort of smaller set of `__asan_*` intrinsics tocall as well. In the end what's happening though is that fibers, uponterminating, have a few frames of Rust code on the stack beforeswitching off. To ASAN these frames never returned so when a stack issubsequently reused ASAN is tricked into thinking this is bufferoverflow or use-after-free since it's stomping on frames that haven'treturned.The fix in this commit is to avoid this style of function which doesn'treturns. Functions which don't return in Rust are easy to leak memoryfrom and are a hazard from a safety perspective as well (e.g. it'sunsafe to skip running destructors of stack variables). I feel we've hadbetter success over time with "all Rust functions always return" and sowhat's what was applied here. Unlike #12899 or my thoughts on that PRthis does not have any new `__asan_*` intrinsic calls. Instead what thisdoes is it shuffles around responsibility for what exact piece of theinfrastructure is responsible for what. Specifically `fiber_start`functions now actually return, meaning the `wasmtime_fiber_start` nakedfunction actually resumes execution, unlike before. The`wasmtime_fiber_start` then delegates to `wasmtime_fiber_switch`immediately to perform the final switch.Effectively there's now only two function frames that never return, andboth of these frames are handwritten inline assembly. This means thatASAN gets to see that all normal functions return and updates all of itsmetadata accordingly. The end result is that the original issue from #12899is fixed and this I feel is in general more robust as well.One caveat is that the handwritten `wasmtime_fiber_start` assembly needsto invoke a sibling `wasmtime_fiber_switch_` function. In lieu of tryingto figure out how to get PIC-vs-not calls working (e.g. static calls)I've opted to use indirect function calls and pointers instead. Thismirrors historical changes in our fiber implementation too.* Fix CI builds* Fix miri List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

4b661a24 - Fix some overflows when allocating a max-size fiber stack (#12868)

Mon, 30 Mar 2026 23:49:43 +0000

Fix some overflows when allocating a max-size fiber stack (#12868)* Fix some overflows when allocating a max-size fiber stackThese are some minor issues that won't actually surface in practice butseem good to fix nonetheless. Allocating a max-size fiber stack shouldfail, and it shouldn't fail with a panic or a debug assert.* Fix CI List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

7da79ce3 - wasmtime-fiber: use `wasmtime_environ::error` instead of `anyhow` (#12206)

Tue, 23 Dec 2025 17:04:11 +0000

wasmtime-fiber: use `wasmtime_environ::error` instead of `anyhow` (#12206)* wasmtime-fiber: use `wasmtime_environ::error` instead of `anyhow`* Fix publish script topological sorting List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

3e9eca8b - Use `naked_asm!`, delete `asm_func!` (#11405)

Thu, 18 Sep 2025 20:23:41 +0000

Use `naked_asm!`, delete `asm_func!` (#11405)This deletes our home-grown `asm_func!` macro in favor of using`#[unsafe(naked)]` functions within Wasmtime. This is needed forfiber-related bits right now where we need tight control over the exactassembly of some functions. This additionally migrates s390x fiber bitsto Rust as inline assembly is now stable for s390x.prtest:full List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

3d67b75e - Add a dummy impl of fibers for Miri (#11009)

Wed, 11 Jun 2025 00:47:47 +0000

Add a dummy impl of fibers for Miri (#11009)* Add a dummy impl of fibers for MiriThis commit extends the `wasmtime-internal-fiber` crate with animplementation for Miri. Previously this was entirely unsupportedbecause fibers use inline assembly. The implementation with Miri spawnsa separate thread and keeps it in a suspended state with locks to modela suspended stack. This technically isn't correct because TLS variableswill be wrong, but it's "correct enough" for our usage in Wasmtime. Inthe end this enables running more tests in Miri which is always a goodthing, and a number of loose odds and ends were cleaned up relate to ourunsafe management of async state.* Apply suggestions from code reviewCo-authored-by: Pat Hickey ---------Co-authored-by: Pat Hickey List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

4c8edb95 - More clearly flag internal crates as such (#10963)

Fri, 06 Jun 2025 21:13:36 +0000

More clearly flag internal crates as such (#10963)* More clearly flag internal crates as suchThis commit is an attempt to more clearly flag internal crates in thisproject as internal and not intended for external use. Specifically:* Many crates are renamed from `wasmtime-foo` to `wasmtime-internal-foo`.* All of these crates now have `INTERNAL: ...` in their crates.io description.* All of these crates now have a warning at the top of their documentation discouraging use.This change is a result of rustsec/advisory-db#1999 where the goal is tobe crystal clear from a project perspective that usage of these cratesare highly discouraged and not supported. We'll still probably get suchadvisories but we won't be considering them CVEs from the project itselfdue to the internal nature of these crates and the discouragingwarnings.Some concrete changes used here are:* Inter-crate dependencies still use `wasmtime_foo` for naming and do so with Cargo's package-renaming features.* Crate renames are specified at the workspace level so the rename is only in one locations and all other inherit it.* Contribution documentation now has some brief guidelines about crate organization.* Update vet config* Update checks for wasmtime-fiberprtest:full* Update publish script* Another fiber rename* Fix some doc tests List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

b3fa9bfa - Duplicate page size determination in `wasmtime-fiber` (#10803)

Wed, 21 May 2025 23:50:43 +0000

Duplicate page size determination in `wasmtime-fiber` (#10803)* Duplicate page size determination in `wasmtime-fiber`Currently Wasmtime has a function `crate::runtime::vm::host_page_size`but this isn't reachable from the `wasmtime-fiber` crate and instead thacrate uses `rustix::param::page_size` to determine the host page size.It looks like this usage of `rustix` is causing a panic in #10802.Ideally `wasmtime-fiber` would be able to use the same function but thecrate separation does not currently make that feasible. For nowduplicate the logic of `wasmtime` into `wasmtime-fiber` as it's modestenough to ensure that this does not panic.Closes #10802* Run full test suite in CIprtest:full List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

7a66c39a - Remove some `#![expect(clippy::allow_attributes_without_reason)]` (#10661)

Wed, 23 Apr 2025 21:07:33 +0000

Remove some `#![expect(clippy::allow_attributes_without_reason)]` (#10661)Clean up some crates by migrating from `#[allow]` to `#[expect]`(ideally) or `#[allow]`-with-reason List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

e657756d - Run CI tests through AddressSanitizer (#10537)

Thu, 10 Apr 2025 15:35:08 +0000

Run CI tests through AddressSanitizer (#10537)This is similar to running tests in Valgrind (which we should perhapsalso do...) but can be useful for catching use-after-free style bugsfaster than when a process crashes. Given the unsafe nature of Wasmtimethis is something we should have probably enabled awhile back butotherwise so long as it doesn't take too long to run on CI seems like aneasy win of a boost-of-confidence.prtest:asan List of files: /wasmtime-44.0.1/crates/fiber/src/lib.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/crates/fiber/src/lib.rs

980a136e - Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)

Thu, 16 Jan 2025 00:23:13 +0000

Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)* Wasmtime: generalize `async_stack_zeroing` knob to cover initializationThis commit moves the knob from the `PoolingInstanceAllocatorConfig` to theregular `Config` and now controls both whether stacks are zeroed before reuseand whether they are zeroed before the initial use. The latter doesn't matterusually, since anonymous mmaps are already zeroed so we don't have to doanything there, but for no-std environments it is the difference betweenmanually zeroing the stack or simply using unininitialized memory.* Fix CLI and test builds* fix default config value* fix some more tests List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

abcd6acc - Port wasmtime-fiber to `no_std` and allow `async` feature in `no_std` Wasmtime. (#9689)

Wed, 04 Dec 2024 19:31:21 +0000

Port wasmtime-fiber to `no_std` and allow `async` feature in `no_std` Wasmtime. (#9689)This PR allows a `no_std` Wasmtime build to be configured with the`async` feature. (Previously, a minimal `no_std` configuration couldonly run with sync entry points, without suspending of stacks.)The main hurdle to this support was the `wasmtime-fiber` crate.Fortunately, the "unix" variant of fibers was almost entirely portableto a `no_std` environment, owing to the fact that it implementsstack-switching manually in assembly itself. I moved the per-ISAimplementations to a shared submodule and built the nostd platformbackend for `wasmtime-fiber` with a stripped-down version of the unixbackend.The nostd backend does not support mmap'd stacks, does not supportcustom stack allocators, and does not propagate panics.prtest:full List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

45b60bd6 - Start using `#[expect]` instead of `#[allow]` (#9696)

Mon, 02 Dec 2024 17:19:20 +0000

Start using `#[expect]` instead of `#[allow]` (#9696)* Start using `#[expect]` instead of `#[allow]`In Rust 1.81, our new MSRV, a new feature was added to Rust to use`#[expect]` to control lint levels. This new lint annotation willsilence a lint but will itself cause a lint if it doesn't actuallysilence anything. This is quite useful to ensure that annotations don'tget stale over time.Another feature is the ability to use a `reason` directive on theattribute with a string explaining why the attribute is there. Thisstring is then rendered in compiler messages if a warning or errorhappens.This commit migrates applies a few changes across the workspace:* Some `#[allow]` are changed to `#[expect]` with a `reason`.* Some `#[allow]` have a `reason` added if the lint conditionally fires (mostly related to macros).* Some `#[allow]` are removed since the lint doesn't actually fire.* The workspace configures `clippy::allow_attributes_without_reason = 'warn'` as a "ratchet" to prevent future regressions.* Many crates are annotated to allow `allow_attributes_without_reason` during this transitionary period.The end-state is that all crates should use`#[expect(..., reason = "...")]` for any lint that unconditionally firesbut is expected. The `#[allow(..., reason = "...")]` lint should be usedfor conditionally firing lints, primarily in macro-related code.The `allow_attributes_without_reason = 'warn'` level is intended to bepermanent but the transitionary`#[expect(clippy::allow_attributes_without_reason)]` crate annotationsto go away over time.* Fix adapter buildprtest:full* Fix one-core build of icache coherence* Use `allow` for missing_docsWork around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn'tfixed for our MSRV at this time.* More MSRV compat List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

7bd09e6e - Store one fiber stack in a `Store` (#9604)

Thu, 14 Nov 2024 20:51:45 +0000

Store one fiber stack in a `Store` (#9604)* Store one fiber stack in a `Store`This commit stores a single fiber stack in `Store` as a cache to beused throughout the lifetime of the `Store`. This should help amortizethe cost of allocating a stack for use in a store because the same stackcan be used continuously throughout the lifetime of the `Store`. Thisnotably reduces contention on the lock used to manage the poolingallocator when possible.* Fix non-async build List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

110e70f3 - Print an error on async stack overflow (#9304)

Thu, 26 Sep 2024 04:12:12 +0000

Print an error on async stack overflow (#9304)* Print an error on async stack overflowThis commit updates Wasmtime's handling of traps on Unix platforms toprint an error message on stack overflow when the guard page is hit.This is distinct from stack overflow in WebAssembly which raises anormal trap and can be caught. This is instead to be used onmisconfigured hosts where the async stack is too small or wasm wasallowed to take up too much of the async stack. Currently no errormessage is printed and the program simply aborts with a core dump whichcan be difficult to debug.This instead registers the range of the async guard page with the traphandling infrastructure to test the faulting address and if it lieswithin this range. If so then a small message is printed and then theprogram is aborted with `libc::abort()`.This does not impact the safety of any prior embedding or fix anyissues. It's instead intended purely as a diagnostic tool to help usersmore quickly understand that stack size configuration settings are thelikely culprit.* Fix build of c-api and testsprtest:full* Fix build on Windows* Fix a warning on Windows* Fix dead code on miri List of files: /wasmtime-44.0.1/crates/fiber/src/lib.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/fiber/src/lib.rs

169b97fc - Build and test wasmtime-fiber on i686/arm (#9035)

Mon, 29 Jul 2024 17:25:09 +0000

Build and test wasmtime-fiber on i686/arm (#9035)Now that we've got CI for Pulley throw in `wasmtime-fiber` as well witha few extra fixes. This should also help improve the compilationexperience of Wasmtime to 32-bit platforms to hit a more first-classerror about unsupported platforms. List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

e1f8b9b7 - Wasmtime(pooling allocator): Batch decommits (#8590)

Tue, 14 May 2024 00:23:17 +0000

Wasmtime(pooling allocator): Batch decommits (#8590)This introduces a `DecommitQueue` for batching decommits together in the poolingallocator:* Deallocating a memory/table/stack enqueues their associated regions of memory for decommit; it no longer immediately returns the associated slot to the pool's free list. If the queue's length has reached the configured batch size, then we flush the queue by running all the decommits, and finally returning the memory/table/stack slots to their respective pools and free lists.* Additionally, if allocating a new memory/table/stack fails because the free list is empty (aka we've reached the max concurrently-allocated limit for this entity) then we fall back to a slow path before propagating the error. This slow path flushes the decommit queue and then retries allocation, hoping that the queue flush reclaimed slots and made them available for this fallback allocation attempt. This involved defining a new `PoolConcurrencyLimitError` to match on, which is also exposed in the public embedder API.It is also worth noting that we *always* use this new decommit queue now. Tokeep the existing behavior, where e.g. a memory's decommits happen immediatelyon deallocation, you can use a batch size of one. This effectively disablesqueueing, forcing all decommits to be flushed immediately.The default decommit batch size is one.This commit, with batch size of one, consistently gives me an increase on`wasmtime serve`'s requests-per-second versus its parent commit, as measured by`benches/wasmtime-serve-rps.sh`. I get ~39K RPS on this commit compared to ~35KRPS on the parent commit. This is quite puzzling to me. I was expecting nochange, and hoping there wouldn't be a regression. I was not expecting a speedup. I cannot explain this result at this time.prtest:fullCo-authored-by: Jamey Sharp List of files: /wasmtime-44.0.1/crates/fiber/src/lib.rs

b4ecea38 - Add a fuzzer for async wasm (#8440)

Tue, 23 Apr 2024 19:18:09 +0000

Add a fuzzer for async wasm (#8440)* Add a fuzzer for async wasmThis commit revives a very old branch of mine to add a fuzzer forWasmtime in async mode. This work was originally blocked onllvm/llvm-project#53891 and while that's still an issue it now containsa workaround for that issue. Support for async fuzzing required a gooddeal of refactorings and changes, and the highlights are:* The main part is that new intrinsics, `__sanitizer_{start,finish}_fiber_switch` are now invoked around the stack-switching routines of fibers. This only works on Unix and is set to only compile when ASAN is enabled (otherwise everything is a noop). This required refactoring of things to get it all in just the right way for ASAN since it appears that these functions not only need to be called but more-or-less need to be adjacent to each other in the code. My guess is that while we're switching ASAN is in a "weird state" and it's not ready to run arbitrary code.* Stacks are a problem. The above issue in LLVM outlines how stacks cannot be deallocated at this time because if the deallocated virtual memory is later used for the heap then ASAN will have a false positive about stack overflow. To handle this stacks are specially handled in asan mode by using a special allocation path that never deallocates stacks. This logic additionally applies to the pooling allocator which uses a different stack allocation strategy with ASAN.With all of the above a new fuzzer is added. This fuzzer generates anarbitrary module, selects an arbitrary means of async (e.g.epochs/fuel), and then tries to execute the exports of the module withvarious values. In general the fuzzer is looking for crashes/panics asopposed to correct answers as there's no oracle here. This is alsointended to stress the code used to switch on and off stacks.* Fix non-async build* Remove unused import* Review comments* Fix compile on MIRI* Fix Windows build List of files: /wasmtime-44.0.1/crates/fiber/src/lib.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/crates/fiber/src/lib.rs