Ptr::copy_nonoverlapping panic

Hello! I have a piece of code that allows calling C functions. Linux/Docker and OSX.

I am using long jumps to handle problems in FFI-land before they hit the rust code.

In OSX/Mach the signal handling is reliable.

But in linux/Docker (I pulled rust:latest) when I force a segmentation fault in the hope of hitting the signal handler, I am seeing this "../sysdeps/.../memmove-ve-unaligned-erms,S" missing FIRST. Then gdb hits my signal handler. Continuing from there causes the panic.

The message seems related to the missing .S file.

Are these related?

void handle_signal(int s)
{
longjump(*long_jump_struct, s);
}
[Switching to Thread 0x7ffff61286c0 (LWP 1090)]
__memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:352
352 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) c
Continuing.
Thread 13 "XXXXXXX" hit Breakpoint 1, handle_signal (s=11) at src/c/lib.c:22
22 **longjmp**(*_long_jump, s);
(gdb) s
thread 'XXXXXX' panicked at core/src/panicking.rs:221:5:
unsafe precondition(s) violated: ptr::copy_nonoverlapping requires that both pointer arguments are aligned and non-null and the specified memory ranges do not overlap
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread caused non-unwinding panic. aborting.

rustc 1.83
rust image is 6440c73bd6c

Can you show a backtrace? You can use the bt/backtrace gdb command.

They are NOT related.

The panic was caused by different behaviors between OSX and Linux of copy_from_slice/slice::from_raw_parts after coming back from FFI-land. An oversight on my behalf also helped.

Rearranging my code fixes the issue. Thanks!