Hello,
I just updated from wasm-tools from 1.239.0 to 1.249.0. And now I have files that previously could be turned into components with wasm-tools component new now fail with
error: failed to encode a component from module
Caused by:
0: failed to validate component output
1: mismatch in page size for memories (at offset 0x33c9)
I suspect that this is linked to the fact that I have a memory with pagesize 0x1 and is caused by https://github.com/bytecodealliance/wasm-tools/pull/2477. I only have a single memory though that I'm not sure that I understand where's the problem
cc @Alex Crichton since you're the author of the linked PR.
Ah yeah this is from that PR because previously we didn't check all the components of the memory type. Technically the component model doesn't integrate with the custom-page-sizes proposal, but I think this would be reasonable to relax for wasm-tools. @Antoine Lavandier would you be up for sending a PR for this?
Sure. That being said, when you say that it would make sense to relax it for wasm-tools. Would you also be open to relax it for wasmtime ? Also, what's the best way to do this ? Currently all memories are checked to be subtypes of MemoryType { initial: 0, maximum: None, memory64: ty.memory64, shared: false, page_size_log2: None };Should we remove this check ? Check against pages_size_log2: Some(0) and page_size_log2: Some(16) and only fail if none work ?
For Wasmtime and wasm-tools we'll still want to require -Wcustom-page-sizes as an opt-in to enable that feature, but I would agree that there shouldn't be any necessary feature other than that.
For wasm-tools it'd probably be easiest to update the check to pick up the page_size_log2 from the original type itself so that way it's guaranteed to be compatible
I have opened a PR for this in the wasm-tools repo. For now I'm sticking with wasm-tools 1.246.0 and wasmtime 43 since they're the newest version that still allow component with custom page sizes.
Last updated: Jun 01 2026 at 09:49 UTC