ICE with `rustc --version | false`

[lilyball]

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]

Closing as a dupe of #13824

[pnkfelix]

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

[lilyball]

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]

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

[shaleh]

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]

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

[shaleh]

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]

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]

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.