Weird sometimes crash with Drop on x86_64-apple-darwin

I've encountered a crash when running a debug build of some code that implements a custom Drop function. It only appears to happen on the x86_64-apple-darwin target built in debug mode, but I do not have access to every target to test against.

I'm not sure if it is an error on my part implementing the drop trait for a collection that uses raw pointers, or if it may be a compiler code gen bug? I do not know enough about lower level assembly to be able to diagnose, so I was hoping someone here might be able to shed some light on why this is happening...?

Here is a MVC - https://github.com/nathansizemore/weird-drop

weird-drop/bin contains a simple cargo generated bin project for reproducing the crash.

Without a debugger, I received the message

$ cargo run --verbose
error: Process didn't exit successfully: `target/debug/bin` (signal: 11, SIGSEGV: invalid memory reference)

Info from LLDB

Process 47052 stopped
* thread #1: tid = 0x4705e, 0x00007fff9396c5de libsystem_malloc.dylib`tiny_free_list_remove_ptr + 267, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x18)
    frame #0: 0x00007fff9396c5de libsystem_malloc.dylib`tiny_free_list_remove_ptr + 267
libsystem_malloc.dylib`tiny_free_list_remove_ptr:
->  0x7fff9396c5de <+267>: movq   %rax, 0x8(%rcx)
    0x7fff9396c5e2 <+271>: testq  %r14, %r14
    0x7fff9396c5e5 <+274>: jne    0x7fff9396c605            ; <+306>
    0x7fff9396c5e7 <+276>: jmp    0x7fff9396c625            ; <+338>
Things that do not cause crash
  • If the print! macro is used
  • Built with -O3
  • --target=x86_64-unknown-linux-gnu
self.num_elems += 1;
let next_elem_offset = self.num_elems as isize;

I think you need to swap these lines. When there's one element, it goes at the 0th offset, etc etc

Boom! Thanks!
Wow, can't believe I missed that. Wonder why that seems to only break it during debug build?

At least on Linux, it doesn't crash for me either way, but valgrind complains about invalid writes on both debug and release builds. But I get three of those errors on the debug build, and only two on the release build, so clearly the optimizer is eliding some writes.