Stream: git-wasmtime

Topic: wasmtime / issue #12053 Custom MemoryCreator no longer re...

Wasmtime GitHub notifications bot (Nov 20 2025 at 07:46):

d-sonuga opened issue #12053:

Hi,

I've run into an issue after upgrading from Wasmtime 21 to 33, specifically around the behavior of a custom MemoryCreator implementation. I'm using a custom memory creator that allocates memory using mmaped pages. When the memory is modified, those changes are persisted to disk. On startup, the memory creator reconstructs linear memory from the persisted pages.

This setup works fine on Wasmtime 21.
However, on Wasmtime 33 (and 38), the behavior changes: the custom-created memory region appears not to be modified, even though the wasm module executes normally. It looks like Wasmtime doesn't actually modify the memory returned by the MemoryCreator.

My suspicion is that something in Wasmtime's internal memory handling changed, but I'm not certain.

This is the configuration:

config.wasm_backtrace(false);
config.wasm_backtrace_details(WasmBacktraceDetails::Disable);
config.native_unwind_info(false);
config.max_wasm_stack(0x80000);
config.consume_fuel(true);
config.strategy(Strategy::Cranelift);
config.cranelift_opt_level(OptLevel::SpeedAndSize);
config.cranelift_nan_canonicalization(true);
config.memory_may_move(false);
config.memory_guard_size(0);
config.guard_before_linear_memory(false);
config.memory_init_cow(false);
config.generate_address_map(false);
config.macos_use_mach_ports(false);
config.wasm_memory64(true);

The with_host_memory is called later on to set the memory creator.

@alexcrichton?

Wasmtime GitHub notifications bot (Nov 20 2025 at 08:48):

d-sonuga commented on issue #12053:

Update: the memory actually gets written - the mmap page faults are being triggered and handled correctly - I think the reason is because of instance initialization - the memory keeps getting reinitialized, even when it shouldn't, the needs_init has been removed from the LinearMemory implementation - I think that's it - what was it replaced with?

Wasmtime GitHub notifications bot (Nov 20 2025 at 09:31):

d-sonuga commented on issue #12053:

Update: sorry, it's not Wasmtime that changed. The problem was on my side.

Wasmtime GitHub notifications bot (Nov 20 2025 at 15:23):

alexcrichton closed issue #12053:

Hi,

I've run into an issue after upgrading from Wasmtime 21 to 33, specifically around the behavior of a custom MemoryCreator implementation. I'm using a custom memory creator that allocates memory using mmaped pages. When the memory is modified, those changes are persisted to disk. On startup, the memory creator reconstructs linear memory from the persisted pages.

This setup works fine on Wasmtime 21.
However, on Wasmtime 33 (and 38), the behavior changes: the custom-created memory region appears not to be modified, even though the wasm module executes normally. It looks like Wasmtime doesn't actually modify the memory returned by the MemoryCreator.

My suspicion is that something in Wasmtime's internal memory handling changed, but I'm not certain.

This is the configuration:

config.wasm_backtrace(false);
config.wasm_backtrace_details(WasmBacktraceDetails::Disable);
config.native_unwind_info(false);
config.max_wasm_stack(0x80000);
config.consume_fuel(true);
config.strategy(Strategy::Cranelift);
config.cranelift_opt_level(OptLevel::SpeedAndSize);
config.cranelift_nan_canonicalization(true);
config.memory_may_move(false);
config.memory_guard_size(0);
config.guard_before_linear_memory(false);
config.memory_init_cow(false);
config.generate_address_map(false);
config.macos_use_mach_ports(false);
config.wasm_memory64(true);

The with_host_memory is called later on to set the memory creator.

@alexcrichton?

Wasmtime GitHub notifications bot (Nov 20 2025 at 15:23):

alexcrichton commented on issue #12053:

Ah no worries! I wouldn't rule out something changing on the Wasmtime side as well, so if that shows up feel free to comment here and I can reopen

Last updated: Dec 06 2025 at 06:05 UTC