Skip to content

ICE with rustc --version | false #14505

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
lilyball opened this issue May 29, 2014 · 10 comments
Closed

ICE with rustc --version | false #14505

lilyball opened this issue May 29, 2014 · 10 comments
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@lilyball
Copy link
Contributor

Attempting to run rustc --version with a closed stdout will ICE:

> rustc --version | false
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://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task '<main>' failed at 'failed printing to stdout: broken pipe (Broken pipe)', /Users/kevin/Dev/rust/rust/src/libstd/io/stdio.rs:245
@alexcrichton
Copy link
Member

Closing as a dupe of #13824

@pnkfelix
Copy link
Member

reopening; #13824 did not address the fact that this ICE's.

@pnkfelix pnkfelix reopened this Apr 18, 2015
@steveklabnik steveklabnik added the I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ label Apr 22, 2015
@lilyball
Copy link
Contributor Author

Hmm, I thought print!() and println!() were supposed to ignore failures when printing to stdout. But the code explicitly panics:

    if let Err(e) = result {
        panic!("failed printing to stdout: {}", e);
    }

Note that the docs on print!() / println!() do not actually document how they handle errors, but the natural assumption would be to ignore them, because panicking simply because stdout had an error seems very unexpected.

@remram44
Copy link
Contributor

println!() still panics on broken pipe (rust nightly 0fc0476e6 2015-05-24), and it's still not in the doc 😞

@shaleh
Copy link

shaleh commented Aug 28, 2015

This is a little more annoying than just println! too.

loop
{
    match write!(&mut io::stdout(), "{}\n", output)
    {
        Ok(_) => {},
        Err(e) => {
            if e.kind() == io::ErrorKind::BrokenPipe {
                break
            } else {
                panic!("My {}", e)
            }
        },
    }

See, I tried to catch the write failure and I couldn't because the panic happened deeper than the code could reach. Same thing happens with io::stdout().write(). Both of which look to be lower level than println!. This makes piping ANY rust program a recipe for failure at some point.

If there is a work around please document it.

@remram44
Copy link
Contributor

@shaleh: I'm not sure I follow this one? It does break correctly here.

@shaleh
Copy link

shaleh commented Aug 28, 2015

Did you try it? I have a BrokenPipe handler but the thread is still killed. Yes the break happens but then the program still dies.

thread '<main>' panicked at 'failed printing to stdout: Broken pipe (os error 32)', ../src/libstd/io/stdio.rs:474

I can panic! myself but I cannot ignore the panic.

@remram44
Copy link
Contributor

Here's my code: gist

$ ./test | false
breaking
got out of the loop alive

[edit: tested on Mac and Linux, didn't try on Windows]

@shaleh
Copy link

shaleh commented Aug 29, 2015

Grumble. My version of the code was in a function called by main. There was a debug print still hiding in main so I caught the pipe in my function and then another one was triggered by the debug print in main.

Well, at least we have a solution to the SIGPIPE to add to the documentation. That will save others the pain.

@steveklabnik
Copy link
Member

This has now been fixed! I don't know how, exactly, but glacier alerted me a few days ago.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

6 participants