Restore wasmtime's default stack size limit to 1MB
#11993
Conversation
koute
added
A0-please_review
|
Hmm... okay, this is interesting. Apparently when you compile with We potentially might need to slightly rethink these tests if they end up being too flake-y (e.g. only guarantee the minimum call stack depth, but not enforce the maximum), but I'd still like to try having them as is. If nothing else we can learn from this what factors can affect the maximum call stack depth. |
Correct. This isn't supposed to be truly exhaustive (as that would be a lot more involved); I just wanted to have something so that this doesn't accidentally happen again under our noses ever again. |
| // existing chain from syncing (if it was effectively decreased) | ||
|
|
||
| // We need two limits here since depending on whether the code is compiled in debug | ||
| // or in release mode the maximum call depth is slightly different. |
There was a problem hiding this comment.
There was a problem hiding this comment.
Okay, that's good to know. Thanks!
|
bot merge |
* Restore `wasmtime`'s default stack size limit to 1MB * Add extra comments * Enforce different maximum call depth in release mode * Split the call depth limit in two
* Restore `wasmtime`'s default stack size limit to 1MB * Add extra comments * Enforce different maximum call depth in release mode * Split the call depth limit in two
Fixes #11891
This PR restores
wasmtime's default stack size limit to 1MB.Originally
wasmtime's default stack size limit was set to 1MB, however in version 0.35 it was changed to 512 KB for reasons which aren't really relevant to us. This flew under the radar until our friends from the Astar parachain noticed that this broke their ability to sync their parachain from scratch.So this PR simply restores the original limit.
I've also added two extra tests to more closely enforce this limit. Please note that since they test the exact boundary in theory they may also fail if anything else changes related to how much stack space a single frame takes without us modifying the stack limit. This is intended; we don't want this to change under us without us knowing about it.
(We might have to
#[cfg]-gate these test by architecture and/or OS, but I didn't want to blindly do it until I'll see a failing CI job and/or someone complaining that it fails on their machine.)