Wrong size passed to free in issue-26709.rs run-pass test (yielding jemalloc assert fail)

[nagisa]

After ./configure --enable-rpath --disable-clang --disable-libcpp --enable-llvm-assertions --release-channel=dev --enable-debug --enable-optimize on linux, running tests will fail with:

---- [run-pass] run-pass/issue-26709.rs stdout ----

error: test run failed!
status: signal: 6
command: x86_64-unknown-linux-gnu/test/run-pass/issue-26709.stage1-x86_64-unknown-linux-gnu 
stdout:
------------------------------------------
 
------------------------------------------
stderr:
------------------------------------------
<jemalloc>: /home/nagisa/Documents/rust/rust/src/jemalloc/src/jemalloc.c:1885: Failed assertion: "usize == isalloc(ptr, config_prof)"
 
------------------------------------------
 
thread '[run-pass] run-pass/issue-26709.rs' panicked at 'explicit panic', /home/nagisa/Documents/rust/rust/src/compiletest/runtest.rs:1490

I should make it clear I have no minimal reproduction and am not even sure whether configure flags. my system configuration or any local state have anything to do with reproducability.

[elinorbgr]

I also reproduce this running make check-stage1-rpass on my 64bits linux with this configure:

./configure --llvm-root=/usr/ --enable-debug --disable-docs --enable-optimize

[pnkfelix]

I can reproduce this as well on my Mac. (After applying #27139 to get around debuginfo issues, I then hit this bug; configure flags --enable-debug --enable-optimize --enable-ccache --enable-clang --disable-optimize-tests --disable-llvm-assertions --disable-debuginfo)

[pnkfelix]

(flagging as I-crash because jemalloc assert fails sound especially scary, in terms of potential threat, to me.)

[alexcrichton]

Looks like this is indeed a memory unsafety bug. We're allocating a chunk of memory with a size of 16 bytes and then deallocating it with the size of 20 bytes. This was never found because jemalloc assertions are normally disabled, but --enable-debug builds enable these assertions. Optimization and debuginfo are unrelated to this bug.

To see this in action, this program will abort because the assertion in exchange_free is tripped. Note that this doesn't print anything, it just aborts:

#![feature(no_std, lang_items, start, box_syntax, unsize, unique, core_prelude)]
#![feature(core, coerce_unsized, core_intrinsics, libc, linkage)]
#![no_std]
#![allow(improper_ctypes)]

#[macro_use]
extern crate core;
extern crate libc;

use core::prelude::*;
use core::ptr::Unique;
use core::marker::Unsize;
use core::ops::CoerceUnsized;

struct Wrapper<'a, T: ?Sized>(&'a mut i32, T);

impl<'a, T: ?Sized> Drop for Wrapper<'a, T> {
    fn drop(&mut self) {}
}

#[lang = "owned_box"]
struct Box<T>(Unique<T>);
impl<T: ?Sized+Unsize<U>, U: ?Sized> CoerceUnsized<Box<U>> for Box<T> {}

#[start]
fn start(_argc: isize, _argv: *const *const u8) -> isize {
    let mut x = 3;
    let wrapper: Box<Wrapper<i32>> = box Wrapper(&mut x, 123);
    let _: Box<Wrapper<Send>> = wrapper;
    0
}

#[lang = "exchange_malloc"]
unsafe fn exchange_malloc(size: usize, align: usize) -> *mut u8 {
    assert_eq!(size, 16);
    assert_eq!(align, 8);
    extern {
        fn malloc(size: usize) -> *mut u8;
    }
    malloc(size)
}

#[lang = "exchange_free"]
unsafe fn exchange_free(ptr: *mut u8, old_size: usize, align: usize) {
    assert_eq!(old_size, 16);
    assert_eq!(align, 8);
    extern {
        fn free(ptr: *mut u8);
    }
    free(ptr)
}



#[lang = "stack_exhausted"] extern fn stack_exhausted() {}
#[lang = "eh_personality"] extern fn eh_personality() {}
#[lang = "panic_fmt"]
#[linkage = "external"]
pub fn panic_fmt() -> ! {
    unsafe { core::intrinsics::abort() }
}

Nominating as this seems like a minor codegen bug (perhaps related to the warning that's printed), but I don't think that it's too too urgent to fix immediately.

[alexcrichton]

Also updated the title a bit.