Misaligned pointer dereference on Mac M1 Pro & Mac M2 Pro

[Eitu33]

We have been encountering the following issue when running wasmer 3.3 and wasmer 4.0 on M1 & M2:

thread 'execution' panicked at 'misaligned pointer dereference: address must be a multiple of 0x10 but is 0x109a5fc18', /Users/thomas/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasmer-vm-4.0.0/src/trap/traphandlers.rs:219:28

rustc 1.72.0-nightly (f4b80cacf 2023-06-30)
binary: rustc
commit-hash: f4b80cacf93ca216c75f6ae12f4b9dec19eba42f
commit-date: 2023-06-30
host: aarch64-apple-darwin
release: 1.72.0-nightly
LLVM version: 16.0.5

This issue is not reproduced on:

• linux_x86_64
• win_x86_64

After looking into the traphandlers.rs code, we noticed that there was a cast made towards the libc::ucontext_t type:

let ucontext = &mut *(context as *mut libc::ucontext_t);

But the used libc::ucontext_t is different depending on the platform, on linux we have:

libc::unix::linux_like::linux::gnu::b64::x86_64
pub struct ucontext_t // size = 936 (0x3A8), align = 0x8

Located at libc-0.2.147/src/unix/linux_like/linux/gnu/b64/x86_64/mod.rs

And for mac we have:

libc::unix::bsd::apple::b64::aarch64::align
pub struct ucontext_t // size = 880 (0x370), align = 0x10

Located at libc-0.2.147/src/unix/bsd/apple/b64/aarch64/align.rs

The context that is being casted into ucontext_t at L219 has its alignment set at 0x08:

context: *mut c_void // size = 8, align = 0x8

This produces a misalignment between the expected 0x10 and the provided 0x08 on these types of mac architectures.

This is currently a big issue for us, if help is required we would be glad to contribute.

[theduke]

@ptitSeb probably a duplicate of #4059 ?

[bilboquet]

@ptitSeb probably a duplicate of #4059 ?

I tested issue #4072 with @Eitu33 who reported it.
So I'm just giving my 2 cents.
I don't think those issues are duplicates as #4072 does not happen on Linux.

[tzemanovic]

we're also hitting this in 2.3.0 in namada-net/namada#1721

[syrusakbary]

Might be related: #4059

[mamcx]

Get same error on M1 16GB with wasmer-vm-3.1.1/src/trap/traphandlers.rs:220:28

[kulakowski]

Note that this is likely becoming visible due to rust-lang/rust#98112 landing in Rust 1.70, which adds debug assertions to misaligned pointer dereferences.

It's possible that macOS does not guarantee this pointer is going to be 16 byte aligned even though a structure within it (the NEON floating point state) is nominally supposed to be. I can't easily find anything about it, you might end up having to file a radar about it. I am sure you can work around it writing out your own less-aligned structure to cast to, though, but that's obviously not fun.

[bilboquet]

Hi,

In the original issue it's not an assert that fails.
It's that cast: context as *mut libc::ucontext_t that causes the panic.
context is *mut c_void

AFAIK, for the cast to work one need align(*mut c_void) >= align(*mut libc::ucontext_t)
but align(*mut c_void) == 0x8 and align(*mut libc::ucontext_t) == 0x10 so obviously the property is not meet.

looking at https://github.com/rust-lang/libc/blob/main/src/unix/bsd/apple/b64/aarch64/align.rs
if ucontext_t is 0x10 align it's because it inherits it's alignment from __darwin_mcontext64 which itself inherits it from __darwin_arm_neon_state64 which is explicitly aligned to 16 here if libc_int128 is not defined.
I guess that if libc_int128 is defined this line pub __v: [::__uint128_t; 32], would also causes the struct to be 16 aligned.

If this is correct (don't' have M1 or M2 so I can't try) this seems to be a dead end, but this would lead me to think that on such platform * c_void should be aligned to 16, so maybe there is something to look on the rust std side.
But pointers are aligned to usize isn't it?

Looking at https://doc.rust-lang.org/beta/core/ffi/enum.c_void.html# I found this

To model pointers to opaque types in FFI, until extern type is stabilized, it is recommended to use a newtype wrapper around an empty byte array. See the Nomicon for details.
I'm not smart enough to find a solution using opaque type (more precisely I think it won't help here), but maybe some else will.

Regards