ICE: opaque error when destination directory doesn't exist

[derwolfe]

Updated description

$ echo 'fn main() {}' | rustc - -o foo/bar/baz                                                                           
error: error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://static.rust-lang.org/doc/master/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'called `Option::unwrap()` on a `None` value', /Users/acrichton/code/rust2/src/libstd/option.rs:264

That's a pretty awful error to hand out for a common-ish error

Original Issue

rustc failed at 'called Option::unwrap() on a None value

This is a bug report.

I received the following error when building a set of tests.

error: error: internal compiler error: unexpected failure
This message reflects a bug in the Rust compiler. 
We would appreciate a bug report: http://static.rust-lang.org/doc/master/complement-bugreport.html
note: the compiler hit an unexpected failure path. this is a bug
Ok(task 'rustc' failed at 'called `Option::unwrap()` on a `None` value', /private/tmp/rust-3RkG/src/libstd/option.rs:148

I have, as of yet, not been able to reproduce the error with a single specific piece of code. I will continue to try and update the ticket once I have done so.

[flaper87]

Would you mind specifying what set of tests you were trying to build? Which test fail specifically? etc.

[huonw]

If you can get a backtrace from the rust_fail symbol that would be useful too. (Also, any code is better than no code at all, so even if you can't reduce it to something really small, still post what you have.)

[derwolfe]

FlaPer87: Sorry, I wasn't very specific. I have a test suite for an application I am writing, i.e. these aren't rust-lang tests that are failing, they are my own. The test suite is failing to build and execute because of the error.

huonw: I'll be able to try to do some more debugging in about 8 hours. I've not run rust under GDB yet, but once I'm able to figure out which file is causing this error, I'll post the backtrace.

[liigo]

Why rustc doesn't print this information even on failed?
2014年3月13日 下午8:50于 "Huon Wilson" notifications@github.com写道：

If you can get a backtrace from the rust_fail symbol that would be useful
too. (Also, any code is better than no code at all, so even if you can't
reduce it to something really small, still post what you have.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12865#issuecomment-37528691
.

[huonw]

@liigo because it wasn't implemented (and is non-trivial to do so). However, we have backtrace-on-fail functionality now that #12602 landed.

[derwolfe]

The compiler is failing with the following code. I am only able to trigger the error when I try to compile with the test:

#[crate_type = "lib"];
#[crate_id = "encode64#0.1"];
#[desc = "Encode hex messages as base64"];

extern crate serialize;

use serialize::base64::{ToBase64, STANDARD};
use serialize::hex::{FromHex};

/// given a string, convert that string to a base64 encoded string.
pub fn encode(to_encode: ~str) -> ~str {
    to_encode.from_hex().unwrap().to_base64(STANDARD)
}

#[test]
fn using_encode(){
    let input  = ~"49276d206b696c6c696e6720796f757220627261696e206c696b65206120706f69736f6e6f7573206d757368726f6f6d";
    let expected = "SSdtIGtpbGxpbmcgeW91ciBicmFpbiBsaWtlIGEgcG9pc29ub3VzIG11c2hyb29t";
    let result = encode(input);
    assert_eq!(result, expected.to_owned());
}

[alexcrichton]

What version of the compiler are you using? That example compiles ok for me both with and without --test

[derwolfe]

Hi Alex - Sorry for the delay, I've been out of town.

checkout: d84a2e4353db019998c20bb11dff4e11b48bbab5
rustc 0.10-pre
host: x86_64-apple-darwin

I'm going to nuke the version and rebuild. I'm using homebrew --HEAD, so I may have gotten a broken intermediate build (though I doubt this, as it is master).

[derwolfe]

Hi - I think I've found the issue.

I nuked and rebuilt from master last night, and the issue still presented itself. But, I noticed that that the directory from which I wanted to run my tests did not exist.

My makefile was trying to create the test binary in a directory that did not exist. Once the directory was created, the issue no longer presented itself.

My apologies for the mix up. If you'd like any other information I would be happy to provide it.

I also changed the code to this:

#[crate_type = "lib"];
#[crate_id = "encode64#0.1"];
#[desc = "Encode hex messages as base64"];

extern crate serialize;

use serialize::base64::{ToBase64, STANDARD};
use serialize::hex::{FromHex};

pub fn encode(to_encode: &str) -> ~str {                                        
    let hexed = to_encode.from_hex();
    if hexed.is_ok() {
            hexed.unwrap().to_base64(STANDARD)                                  
    }
    else {
        ~"error found in hexing"
    }
}

#[test]
fn using_encode(){
    let input  = ~"49276d206b696c6c696e6720796f757220627261696e206c696b65206120\
706f69736f6e6f7573206d757368726f6f6d";
    let expected = ~"SSdtIGtpbGxpbmcgeW91ciBicmFpbiBsaWtlIGEgcG9pc29ub3VzIG11c2\
hyb29t";
    let result = encode(input);
    assert_eq!(result, expected);
}

Thanks.

[alexcrichton]

Updated title and description

[derwolfe]

I'm working on a PR for this. If I'm not mistaken, the affected section just seems to be librustc/lib.rs.

[derwolfe]

I've created a PR for this: #13110

[derwolfe]

While working on this, I've noticed that I can only reproduce the bug on OS X. I ran the test 1000 times on my ubuntu build, and each time it produced the correct error and not the ICE.

I've had enormous difficulty getting debug information that I can use on OS X. I've tried building using RUSTFLAGS="-g" with VERBOSE=1 to check if the build is setting debug flags. It shows it as building with debug information, however gdb doesn't ever seem to be able to find the symbols.

[flaper87]

There are 2 other bugs related to this one that could probably be fixed as part of this too: #13517 and #11107