bytecodealliance / bytecodealliance/wasmtime
Regression for custom LinearMemory implementations: entered unreachable code: memory_image is Some only for mmap-based memories
- Dominant language
- Rust
- Stars
- 18.6k
- Forks
- 1.8k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 121
Description
Hello.
I've been using `wasmtime` with a custom memory implementation that is backed by my custom managed virtual mmap. I don't think the implementation details of my custom struct matter. I've been on wasmtime 25.0 and everything worked fine. After an update to wasmtime 32.0 I had to rewrite the `wasmtime::LinearMemory` impl, but it just got simplified. However, running my code now gets me this panic:
Stacktrace
```
thread 'main' panicked at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/vm/memory.rs:536:29:
internal error: entered unreachable code: memory_image is Some only for mmap-based memories
stack backtrace:
0: __rustc::rust_begin_unwind
at /rustc/a15cce2690e8fab72422515c9dc02c6fbc506733/library/std/src/panicking.rs:697:5
1: core::panicking::panic_fmt
at /rustc/a15cce2690e8fab72422515c9dc02c6fbc506733/library/core/src/panicking.rs:75:14
2: wasmtime::runtime::vm::memory::LocalMemory::new
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/vm/memory.rs:536:29
3: wasmtime::runtime::vm::memory::Memory::new_dynamic
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/vm/memory.rs:240:22
4: ::allocate_memory
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/vm/instance/allocator/on_demand.rs:119:22
5: wasmtime::runtime::vm::instance::allocator::InstanceAllocator::allocate_memories
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/vm/instance/allocator.rs:463:27
6: wasmtime::runtime::vm::instance::allocator::InstanceAllocator::allocate_module::{{closure}}
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/vm/instance/allocator.rs:406:13
7: wasmtime::runtime::vm::instance::allocator::InstanceAllocator::allocate_module
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/vm/instance/allocator.rs:405:15
8: wasmtime::runtime::instance::Instance::new_raw
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/instance.rs:285:13
9: wasmtime::runtime::instance::Instance::new_started_impl
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/instance.rs:207:33
10: wasmtime::runtime::instance::Instance::new_started
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/instance.rs:195:9
11: wasmtime::runtime::instance::InstancePre::instantiate
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/instance.rs:904:18
12: wasmtime::runtime::linker::Linker::instantiate
at /home/mat/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-32.0.0/src/runtime/linker.rs:1097:9
13: anyblox::programs::wasm::WasmProgram::prepare::{{closure}}
at ./anyblox/src/programs/wasm.rs:125:60
...
```
where the prepare function at the bottom is the one that instantiates a module with:
```rs
linker.instantiate(&mut store, &self.module)
```
I see how this gets caused under the hood, namely the `LinearMemoryProxy` always creates a `Raw` memory from a pointer and the `LocalMemory::new` function then enters the unreachable branch, but I don't understand if this is intentional or an overlook during the refactoring between versions 25 and 32.
I'd be interested on why this behaviour changed and if it's possible to restore the ability to use mem images with custom memory implementations. My custom linear memory is backed by an mmap as well, so there should not be any fundamental issues preventing it.
Contributor guide
Assessment
This issue has not been assessed yet.