Weird sometimes crash with Drop on x86_64-apple-darwin


#1

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

#2
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


#3

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


#4

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.