1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
use crate;
use ;
/// An out-of-memory (OOM) error.
///
/// This error is the sentinel for allocation failure due to memory exhaustion.
///
/// Constructing an [`Error`] from an `OutOfMemory` does not allocate.
///
/// Allocation failure inside any `Error` method that must allocate
/// (e.g. [`Error::context`]) will propagate an `OutOfMemory` error.
///
/// # Out-of-Memory Handling in Wasmtime
///
/// Wasmtime performs out-of-memory (OOM) error handling on a **best-effort
/// basis**. OOM handling does not have [tier 1
/// support](https://docs.wasmtime.dev/stability-tiers.html) at this time and,
/// therefore, while failure to handle OOM at some allocation site may be
/// considered a bug, and might be a potential denial-of-service vector, it
/// would not be considered a security vulnerability.[^limits]
///
/// [^limits]: Note that unconstrained guest-controlled resource usage is still
/// considered a vulnerability. Wasmtime has tier 1 support for limiting guest
/// resources, but not for handling OOMs within those limits.
///
/// ## Where Wasmtime Attempts to Handle OOM
///
/// It is important to note that **not all portions of Wasmtime attempt to
/// handle out-of-memory errors**. Notably, Wasmtime only ever attempts to
/// handle OOM in the core *runtime* and never in the *compiler*. No attempt is
/// made to handle allocation failure in the middle of compiling new `Module`s
/// or `Component`s from Wasm to machine code (or Pulley bytecode). However,
/// Wasmtime will attempt to handle OOM when running *pre-compiled* Wasm code
/// (loaded via `Module::deserialize` or `Component::deserialize`).
///
/// Wasmtime's interfaces allow *you* to handle OOM in your own embedding's WASI
/// implementations and host APIs, but Wasmtime's provided WASI implementations
/// (e.g. `wasmtime_wasi_http`) will generally not attempt to handle OOM (as
/// they often depend on third-party crates that do not attempt to handle OOM).
///
/// The API documentation for individual functions and methods that handle OOM
/// should generally document this fact by listing `OutOfMemory` as one of the
/// potential errors returned.
///
/// | **Where** | **Handles OOM?** |
/// |-------------------------------------------------|---------------------------------|
/// | **Compiler** | **No** |
/// |  `wasmtime::Module::new` | No |
/// |  `wasmtime::Component::new` | No |
/// |  `wasmtime::CodeBuilder` | No |
/// |  Other compilation APIs... | No |
/// | **Runtime** | **Yes** |
/// |  `wasmtime::Store` | Yes |
/// |  `wasmtime::Linker` | Yes |
/// |  `wasmtime::Module::deserialize` | Yes |
/// |  `wasmtime::Instance` | Yes |
/// |  `wasmtime::Func::call` | Yes |
/// |  Component Model concurrency/async APIs | Not yet |
/// |  Other instantiation and execution APIs... | Yes |
/// | **WASI Implementations and Host APIs** | **Depends** |
/// |  `wasmtime_wasi` | No |
/// |  `wasmtime_wasi_http` | No |
/// |  `wasmtime_wasi_*` | No |
/// |  Your embedding's APIs | If *you* implement OOM handling |
///
/// If you encounter an unhandled OOM inside Wasmtime, and it is within a
/// portion of code where it should be handled, then please [file an
/// issue](https://github.com/bytecodealliance/wasmtime/issues/new/choose).
///
/// ## Handling More OOMs with Rust Nightly APIs
///
/// Rust's standard library provides fallible allocation APIs, or the necessary
/// building blocks for making our own fallible allocation APIs, for some of its
/// types and collections. For example, it provides `Vec::try_reserve` which can
/// be used to build a fallible version of `Vec::push` and fallible `Box`
/// allocation can be built upon raw allocations from the global allocator and
/// `Box::from_raw`.
///
/// However, the standard library does not provide these things for all the
/// types and collections that Wasmtime uses. Some of these APIs are completely
/// missing (such as a fallible version of
/// `std::collections::hash_map::VacantEntry::insert`) and some APIs exist but
/// are feature-gated on unstable, nightly-only Rust features. The most relevant
/// API from this latter category is
/// [`Arc::try_new`](https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.try_new),
/// as Wasmtime's runtime uses a number of `Arc`s under the covers.
///
/// If handling OOMs is important for your Wasmtime embedding, then you should
/// compile Wasmtime from source using a Nightly Rust toolchain and with the
/// `RUSTFLAGS="--cfg arc_try_new"` environment variable set. This unlocks
/// Wasmtime's internal usage of `Arc::try_new`, making more OOM handling at
/// more allocation sites possible.
// NB: `OutOfMemory`'s representation must be the same as `OomOrDynError`
// (and therefore also `Error`).
// Safety: The `inner` pointer is not a real pointer, it is just bitpacked size
// data.
unsafe
// Safety: The `inner` pointer is not a real pointer, it is just bitpacked size
// data.
unsafe