Memory alignment error in RawPtrBox::new

[viirya]

Describe the bug

When we read array data from IPC, IPC reader basically shares the same memory allocation between Buffers across arrays. These Buffers are just separate slices of an original Buffer.

But this possibly causes memory alignment check error in RawPtrBox::new where an assert verifies if the given pointer is aligned with type T. The alignment offset is computed based on original memory allocation, not these slices.

For example, there are three slices.

let x = [5u8, 6u8, 7u8, 8u8, 9u8];
let y = &x[0..x.len() -1];
let z = [5u8, 6u8, 7u8, 8u8];

Then we compute their alignment offset by:

let ptr = x.as_ptr() as *const u8;
let offset = ptr.align_offset(align_of::<u16>());

The offset of x and y are both 1, and the offset of z is 0.

To Reproduce

Just run cargo test read_generated_files_014 on M1 Macbook. Got:

running 1 test
thread 'read_generated_files_014' panicked at 'assertion failed: `(left == right)`
  left: `8`,
 right: `0`: memory is not aligned', arrow-array/src/raw_pointer.rs:40:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test read_generated_files_014 ... FAILED

failures:

failures:
    read_generated_files_014

Expected behavior

Additional context

[tustvold]

What is the alignment requirement for i128 on an M1 mac, on x86 it is 8 bytes, which is what is guaranteed by the IPC format?

The error message would suggest the buffer is 8 byte aligned, but that this is insufficient for whatever type is being handled.

My hunch is arm requires 16-byte alignment for i128, and following #2857 we are only just now seeing this. I suspect for this case we will need to copy the buffer.

[viirya]

Yes, on M1 Macbook, the alignment for i128 is 16 bytes.

[alamb]

label_issue.py automatically added labels {'arrow'} from #2883