Valgrind error in release, nightly

[antoyo]

Hello.
When compiled in release mode on the nightly channel, the regex crate produces errors when ran in valgrind.
There are no errors in debug mode or in the stable channel, though.

For instance, with the following code:

extern crate regex;

use regex::Regex;

fn main() {
    let regex = Regex::new("[0-9]{3}-[0-9]{3}-[0-9]{4}").unwrap();
    assert_eq!(regex.find("phone: 111-222-3333"), Some((7, 19)));
}

here is the output:

valgrind ./target/release/regexp
==10780== Memcheck, a memory error detector
==10780== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==10780== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==10780== Command: ./target/release/regexp
==10780==
==10780== Conditional jump or move depends on uninitialised value(s)
==10780==    at 0x124DC4: regex::exec::ExecBuilder::build::h91af51d3a0a192dc (in /Tests/regexp/target/release/regexp)
==10780==    by 0x12F3EA: regex::re_unicode::Regex::new::h4b727f8c251debfb (in /Tests/regexp/target/release/regexp)
==10780==    by 0x111F40: regexp::main::hdcf7e35304a9d3aa (in /Tests/regexp/target/release/regexp)
==10780==    by 0x1593C7: std::panicking::try::call::h5df3ac2979db3c90 (in /Tests/regexp/target/release/regexp)
==10780==    by 0x161946: __rust_maybe_catch_panic (in /Tests/regexp/target/release/regexp)
==10780==    by 0x158859: std::rt::lang_start::hfe9ab243c60ffb9b (in /Tests/regexp/target/release/regexp)
==10780==    by 0x548D290: (below main) (in /usr/lib/libc-2.24.so)
==10780==
==10780== Conditional jump or move depends on uninitialised value(s)
==10780==    at 0x118253: regex::compile::Compiler::compile::h3927ede925a12604 (in /Tests/regexp/target/release/regexp)
==10780==    by 0x124FCF: regex::exec::ExecBuilder::build::h91af51d3a0a192dc (in /Tests/regexp/target/release/regexp)
==10780==    by 0x12F3EA: regex::re_unicode::Regex::new::h4b727f8c251debfb (in /Tests/regexp/target/release/regexp)
==10780==    by 0x111F40: regexp::main::hdcf7e35304a9d3aa (in /Tests/regexp/target/release/regexp)
==10780==    by 0x1593C7: std::panicking::try::call::h5df3ac2979db3c90 (in /Tests/regexp/target/release/regexp)
==10780==    by 0x161946: __rust_maybe_catch_panic (in /Tests/regexp/target/release/regexp)
==10780==    by 0x158859: std::rt::lang_start::hfe9ab243c60ffb9b (in /Tests/regexp/target/release/regexp)
==10780==    by 0x548D290: (below main) (in /usr/lib/libc-2.24.so)
==10780==
==10780==
==10780== HEAP SUMMARY:
==10780==     in use at exit: 0 bytes in 0 blocks
==10780==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==10780==
==10780== All heap blocks were freed -- no leaks are possible
==10780==
==10780== For counts of detected and suppressed errors, rerun with: -v
==10780== Use --track-origins=yes to see where uninitialised values come from
==10780== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

Here is the version used:

rustc 1.12.0-nightly (080e0e072 2016-08-08)

Thanks to fix this issue.

[BurntSushi]

Not sure what exactly is going on here. If I add --track-origins=yes to the valgrind command, then I get this:

==15813== Conditional jump or move depends on uninitialised value(s)
==15813==    at 0x122E9B: regex::exec::ExecBuilder::build::hf33bf4d23bea0f6e (exec.rs:279)
==15813==    by 0x12C68E: compile (re_builder.rs:155)
==15813==    by 0x12C68E: with_size_limit (re_unicode.rs:173)
==15813==    by 0x12C68E: regex::re_unicode::Regex::new::h7d713a35eeb45a1c (re_unicode.rs:164)
==15813==    by 0x111F0B: debug::main::h475ce92b4fa06299 (dfa.rs:1444)
==15813==    by 0x15BFBA: __rust_maybe_catch_panic (lib.rs:98)
==15813==    by 0x155866: try<(),fn()> (panicking.rs:434)
==15813==    by 0x155866: catch_unwind<fn(),()> (panic.rs:351)
==15813==    by 0x155866: std::rt::lang_start::ha749a62502c90792 (rt.rs:57)
==15813==    by 0x5697290: (below main) (in /usr/lib/libc-2.24.so)
==15813==  Uninitialised value was created by a stack allocation
==15813==    at 0x12C620: regex::re_unicode::Regex::new::h7d713a35eeb45a1c (re_unicode.rs:163)

Where line 163 of re_unicode.rs is:

    pub fn new(re: &str) -> Result<Regex, Error> {

which is completely innocent. This seems like a false positive?

cc @alexcrichton

[alexcrichton]

Yeah I've basically been conditioned to ignore valgrind on lots of programs due to false positives :(. I wouldn't be surprised if the trace above is a false positive

[antoyo]

In this case, why is this error not showing in release/stable (only shown in nightly)?
I believe there is some change in nightly causing this issue.

[BurntSushi]

@antoyo Sorry for the run-around, but I think that means it's probably better to file this bug against Rust itself. I don't see anything we can do about it unfortunately. :-/