Valgrind shows invalid read/write when using threads

[jethrogb]

// valgrind-test.rs
extern crate vg;

use std::thread;
use std::sync::{Arc,Mutex};
use vg::*;

fn main() {
    let arc=Arc::new(Mutex::new(()));
    let mut threads=vec![];

    for _ in 0..1000 {
        let arc_clone=arc.clone();
        threads.push(thread::spawn(move||{*arc_clone.lock().unwrap();}));
    }

    for t in threads.into_iter() {
        t.join().unwrap();
    }
}

Running like this usually gets me Invalid read/Invalid write errors within 5 executions:

rustc <(echo) -g --crate-type rlib --crate-name vg --out-dir .
rustc valgrind-test.rs -g --extern vg=./libvg.rlib
while valgrind --soname-synonyms=somalloc=NONE --redzone-size=64 --freelist-vol=100000000 --error-exitcode=1 ./valgrind-test ; do test ; done

Some particularly interesting errors are at http://pastebin.com/0m346AT5

The --soname-synonyms=somalloc=NONE option is supposed to make valgrind work properly with statically-linked jemalloc.

It might be my imagination, but it looks like linking to the empty crate significantly increases the chance of Valgrind errors showing up, although not linking this way does not completely eliminate the errors.

Tested on Linux with rust-stable, rust-stable with debug build of libstd only, rust-nightly.

[Aatch]

Looks like it's just a missing into_raw in Thread::new on the passed closure. It looks like the windows version of the code suffers from the same issue.

[alexcrichton]

I'm somewhat wary of valgrind as it often produces false positives. @Aatch can you explain a little more what you found? There is a mem::forget when the thread successfully spawns and otherwise we still have ownership of the closure so it needs to be freed (hence the lack of into_raw).

[Aatch]

@alexcrichton ah, I missed that, sorry.

[steveklabnik]

So is this not a bug then?

[jethrogb]

Could be related to #29106

[jethrogb]

Actually, I can no longer reproduce this with nightly, so closing.