fs::Path.PathExt::exists accesses uninitialized variable

[genodeftest]

When running this test program

#![feature(path_ext)]

use std::path::Path;
use std::fs::PathExt;

fn main() {
    println!("Hello, world!");
    Path::new("/dev/disk/by-uuid/").join("foo").exists();
    println!("Hello, world!");
}

in valgrind, I see the following error message:

==26463== Conditional jump or move depends on uninitialised value(s)
==26463==    at 0x1112DA: fs::Path.PathExt::exists::h3c82b8406965b0063of (in /path/to/project/target/debug/hello_world)
==26463==    by 0x10CDCB: main::h6347461cf51c6d88gaa (main.rs:9)
==26463==    by 0x116E9F: __rust_try_inner (in /path/to/project/target/debug/hello_world)
==26463==    by 0x116EDA: __rust_try (in /path/to/project/target/debug/hello_world)
==26463==    by 0x119267: rt::lang_start::h874802a6840d4e108gx (in /path/to/project/target/debug/hello_world)
==26463==    by 0x10F61B: main (in /path/to/project/target/debug/hello_world)

This happens with the latest rust nightly, but also with older versions. It has been around for at least 2 months. It is reproducible for others too, see e.g. #27316 (comment)

Meta

$ rustc --version --verbose
rustc 1.3.0-nightly (8b835572b 2015-07-27)
binary: rustc
commit-hash: 8b835572b9beacbb4c8faea2bf2943ac3a58977b
commit-date: 2015-07-27
host: x86_64-unknown-linux-gnu
release: 1.3.0-nightly

[apasel422]

Running valgrind with --track-origins=yes reveals:

==16536==  Uninitialised value was created by a stack allocation
==16536==    at 0x1112B2: fs::Path.PathExt::exists::h3c82b8406965b0063of

This isn't that helpful, but it's a start.

[alexcrichton]

Unfortunately valgrind is known to have false positives for checks like this (it's a well known bug between valgrind/LLVM), and this comes as a result of optimized code. It ends up not actually causing problems, and the exact functions which hit this codegen pattern tend to shift over time.

Regardless though I remember investigating this in the past and seeing that it was a false positive, so I don't think there's an issue to resolve here.