RefCell complains two mutable borrows present when only one exist on armv7-unknown-linux-gnueabihf

[MJDSys]

When running the program at: https://is.gd/XHVVMt on my Chromebook (an Asus C201p) with the latest nightly compiler, I get the following error (RUST_BACKTRACE=1):

thread 'main' panicked at 'already borrowed: BorrowMutError', /checkout/src/libcore/result.rs:860
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: <core::result::Result<T, E>>::expect
             at /checkout/src/libcore/result.rs:761
   1: <core::cell::RefCell<T>>::borrow_mut
             at /checkout/src/libcore/cell.rs:740
   2: cell_test::main
             at ./src/main.rs:9

This doesn't occur on the latest stable compiler, and started sometime around March 12. This doesn't happen on my AMD 64bit desktop, nor on playground. Both debug and release builds are affected.

Code:

use std::cell::RefCell;

fn main() {
    let m = RefCell::new(5);
    {
        m.borrow_mut();
    }
    {
        m.borrow_mut();
    }
}

(note the extra scopes don't affect the behaviour.)

[pgerber]

This may be related to rust-openssl/issues/597.

It would appear like dropping of values is broken in the nightly and beta toolchain:

This works:

let mutex = Mutex::new(());
let mut guard = None;
guard = Some(mutex.lock().unwrap());
drop(guard.take().unwrap());
mutex.try_lock().unwrap();     // locks as expected

but this fails:

let mutex = Mutex::new(());
let mut guard = None;
guard = Some(mutex.lock().unwrap());
drop(guard.take());      // unwrap() removed
mutex.try_lock().unwrap();    // panics "WouldBlock"

This seem a rather new issue, in nightly-2017-03-01 it still worked. (May also work in few of the newer versions, haven't had time to try all of them.)

[pgerber]

Tried a few more nightly snapshots nightly-2017-03-04 is the first affected version, nightly-2017-03-03 works flawlessly.

[MJDSys]

@pgerber Where can you find the nightly snapshots? I tried downloading them with rustup.rs, but it said older ones couldn't be found.

[pgerber]

@MJDSys This worked for me:

$ rustup toolchain install nightly-2017-03-03
$ rustup run nightly-2017-03-03 cargo …

[arielb1]

#40133 looks like the main diff. between the 2 versions. Self-assigning.

[arielb1]

@MJDSys

I can't reproduce this on 5d0be0d (03-11) on debian qemu. Could you upload an affected --emit=asm output?

[arielb1]

The first example is optimized out completely on my machine (using xargo run --target=armv7-unknown-linux-gnueabihf --release), so it is unlikely to have issues.

[pgerber]

I get BorrowMutError on my machine too. Here's the ASM output: main.s. Compiled using 4853584 (2017-03-18).

[MJDSys]

@arielb1 Did you run that on an armv7 machine, or on a x86(_64) machine? It seems something really weird is happening in the compiler.

I'm working with a simpler example (see end of this post). A compiler on x86_64 produces a MIR representation that seems to make sense (dropping the option, and then the inner type). However with an armv7 compiler, it doesn't drop the option, but tries to drop the T (while inside the option). I'm not familiar with what the correct representation is, but that is the big difference I see on armv7.

And just to be clear, I need to use a native compiler to see that difference. Cross-compiling the source file does not produce the difference.

If it would help, I'll try to post the different outputs from MIR comparing before/after March 4 between x86_64 and armv7. I also don't think it's an issue in the MIR optimization passes, as when I dump the MIR using -Z dump-mir=all, that difference is always present.

I'm doing all my testing right now with debug builds, but my initial testing before reporting the bug happened with both debug and release.

New example:

#[deny(warnings)]

struct T{}

impl Drop for T {
        fn drop(&mut self) {
                //println!("dropped");
                panic!(false);
        }
}

fn main() {
    {
        Some(T{});
    }
}

[arielb1]

I am using an ARM compiler (rustc 1.17.0-nightly (b1e3176 2017-03-03) aka the Mar 4 nightly) in an x86_64 machine using qemu, which seems not to reproduce the bug. I don't have an ARM machine handy right now,