Misaligned pointer dereference of VMMemoryImport

[gshep]

Describe the bug

Got thread 'main' panicked at 'misaligned pointer dereference: address must be a multiple of 0x8 but is 0x55bf03f10cc4', lib/vm/src/instance/mod.rs:167:18 when run example compiled with nightly rust (source attached below) on amd64 linux.

$ rustc +nightly -vV
rustc 1.72.0-nightly (d9c13cd45 2023-07-05)
binary: rustc
commit-hash: d9c13cd4531649c2028a8384cb4d4e54f985380e
commit-date: 2023-07-05
host: x86_64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.5

wasmer-4.0.0

Steps to reproduce

1. Add the following example which is a modified version of the original instance example

//! Wasmer will let you easily run Wasm module in a Rust host.
//!
//! This example illustrates the basics of using Wasmer through a "Hello World"-like project:
//!
//!   1. How to load a Wasm modules as bytes
//!   2. How to compile the module
//!   3. How to create an instance of the module
//!
//! You can run the example directly by executing in Wasmer root:
//!
//! ```shell
//! cargo run --example imported_memory --release --features "cranelift"
//! ```
//!
//! Ready?

use wasmer::{imports, wat2wasm, Instance, Module, Store, TypedFunction, Memory, MemoryType};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Let's declare the Wasm module.
    //
    // We are using the text representation of the module here but you can also load `.wasm`
    // files using the `include_bytes!` macro.
    let wasm_bytes = wat2wasm(
        br#"
(module
  (type $add_one_t (func (param i32) (result i32)))
  (import "env" "memory" (memory 1))
  (func $add_one_f (type $add_one_t) (param $value i32) (result i32)
    local.get $value
    i32.const 1
    i32.add)
  (export "add_one" (func $add_one_f))
  (data (;0;) (i32.const 0) "\02\00\00\00\04\00\00\00\04\00\00\00\03\00\00\00\04\00\00\00\05\00\00\00library/alloc/src/raw_vec.rscapacity overflow\00\00\004\00\10\00\11\00\00\00\18\00\10\00\1c\00\00\00\0c\02\00\00\05\00\00\00\02\00\00\00\08\00\00\00\04\00\00\00\06\00\00\00memory allocation of  bytes failed\00\00p\00\10\00\15\00\00\00\85\00\10\00\0d\00\00\00library/alloc/src/alloc.rs\00\00\a4\00\10\00\1a\00\00\00\9c\01\00\00\11\00\00\00a formatting trait implementation returned an error\00\02\00\00\00\00\00\00\00\01\00\00\00\07\00\00\00library/alloc/src/fmt.rs\14\01\10\00\18\00\00\00b\02\00\00 \00\00\00called `Option::unwrap()` on a `None` value)library/core/src/fmt/mod.rs..\00\00\00\83\01\10\00\02\00\00\00[\00\00\00\0e\00\00\00\00\00\00\00\01\00\00\00\0f\00\00\00index out of bounds: the len is  but the index is \00\00\a4\01\10\00 \00\00\00\c4\01\10\00\12\00\00\00matches!===assertion failed: `(left  right)`\0a  left: ``,\0a right: ``: \00\00\00\f3\01\10\00\19\00\00\00\0c\02\10\00\12\00\00\00\1e\02\10\00\0c\00\00\00*\02\10\00\03\00\00\00`\00\00\00\f3\01\10\00\19\00\00\00\0c\02\10\00\12\00\00\00\1e\02\10\00\0c\00\00\00P\02\10\00\01\00\00\00: \00\00<\01\10\00\00\00\00\00t\02\10\00\02\00\00\00\0e\00\00\00\0c\00\00\00\04\00\00\00\10\00\00\00\11\00\00\00\12\00\00\00    ,\0a, (\0a(,\0a]library/core/src/fmt/num.rs\00\00\00\ae\02\10\00\1b\00\00\00e\00\00\00\14\00\00\000x00010203040506070809101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899assertion failed: *curr > 19\00\00\ae\02\10\00\1b\00\00\00\e5\01\00\00\05\00\00\00\0e\00\00\00\04\00\00\00\04\00\00\00\13\00\00\00\14\00\00\00\15\00\00\00h\01\10\00\1b\00\00\00\a1\09\00\00\1e\00\00\00h\01\10\00\1b\00\00\00\a8\09\00\00\16\00\00\00range start index  out of range for slice of length \0c\04\10\00\12\00\00\00\1e\04\10\00\22\00\00\00range end index P\04\10\00\10\00\00\00\1e\04\10\00\22\00\00\00slice index starts at  but ends at \00p\04\10\00\16\00\00\00\86\04\10\00\0d\00\00\00\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01\01")
)
"#,
    )?;

    // Create a Store.
    // Note that we don't need to specify the engine/compiler if we want to use
    // the default provided by Wasmer.
    // You can use `Store::default()` for that.
    let mut store = Store::default();

    println!("Compiling module...");
    // Let's compile the Wasm module.
    let module = Module::new(&store, wasm_bytes)?;

    let import_object = imports! {
      "env" => {
          "memory" => Memory::new(&mut store, MemoryType::new(1, None, false)).unwrap(),
      }
    };

    println!("Instantiating module...");
    // Let's instantiate the Wasm module.
    let instance = Instance::new(&mut store, &module, &import_object)?;

    // We now have an instance ready to be used.
    //
    // From an `Instance` we can retrieve any exported entities.
    // Each of these entities is covered in others examples.
    //
    // Here we are retrieving the exported function. We won't go into details here
    // as the main focus of this example is to show how to create an instance out
    // of a Wasm module and have basic interactions with it.
    let add_one: TypedFunction<i32, i32> = instance
        .exports
        .get_function("add_one")?
        .typed(&mut store)?;

    println!("Calling `add_one` function...");
    let result = add_one.call(&mut store, 1)?;

    println!("Results of `add_one`: {:?}", result);
    assert_eq!(result, 2);

    Ok(())
}

#[test]
fn test_exported_function() -> Result<(), Box<dyn std::error::Error>> {
    main()
}

2. Compile and run with cargo +nightly run --example imported-memory --features "cranelift" --profile dev
3. See error

Expected behavior

Actual behavior

Additional context

Maybe relates to #3245

I investigated it a bit and it looks like this is due to the fact that indexes of signatures set to 4 - https://github.com/wasmerio/wasmer/blob/v4.0.0/lib/types/src/vmoffsets.rs#L531. This leads to misaligned pointer on amd64 when there are odd number of function signatures.

[hojarasca]

Some error here. Using 4.1.1

[ptitSeb]

This was fixed with 4.2.0, so closing the issue. Feel free to re-open if you have error with 4.2.0+