Trouble with pipe on OS X

[killerswan]

Today, make check fails like so:

...
running 1280 tests
test [run-pass] run-pass/anon-extern-mod.rs ... ok
test [run-pass] run-pass/alloca-from-derived-tydesc.rs ... ok
test [run-pass] run-pass/alias-uninit-value.rs ... ok
/bin/sh: line 1: 20869 Abort trap: 6           x86_64-apple-darwin/stage2/bin/compiletest --compile-lib-path x86_64-apple-darwin/stage2/lib --run-lib-path x86_64-apple-darwin/stage2/lib/rustc/x86_64-apple-darwin/lib --rustc-path x86_64-apple-darwin/stage2/bin/rustc --clang-path /usr/bin/clang++ --llvm-bin-path /Users/kevin/code/rust/llvm/x86_64-apple-darwin/Release+Asserts/bin --aux-base /Users/kevin/code/rust/src/test/auxiliary/ --stage-id stage2-x86_64-apple-darwin --target x86_64-apple-darwin --adb-path= --adb-test-dir= --rustcflags "   -O --target=x86_64-apple-darwin" --src-base /Users/kevin/code/rust/src/test/run-pass/ --build-base x86_64-apple-darwin/test/run-pass/ --ratchet-metrics tmp/check-stage2-T-x86_64-apple-darwin-H-x86_64-apple-darwin-rpass-metrics.json --mode run-pass --logfile tmp/check-stage2-T-x86_64-apple-darwin-H-x86_64-apple-darwin-rpass.log
make: *** [tmp/check-stage2-T-x86_64-apple-darwin-H-x86_64-apple-darwin-rpass.ok] Error 134

Running that command alone gives the error:

rust $ x86_64-apple-darwin/stage2/bin/compiletest --compile-lib-path x86_64-apple-darwin/stage2/lib --run-lib-path x86_64-apple-darwin/stage2/lib/rustc/x86_64-apple-darwin/lib --rustc-path x86_64-apple-darwin/stage2/bin/rustc --clang-path /usr/bin/clang++ --llvm-bin-path /Users/kevin/code/rust/llvm/x86_64-apple-darwin/Release+Asserts/bin --aux-base /Users/kevin/code/rust/src/test/auxiliary/ --stage-id stage2-x86_64-apple-darwin --target x86_64-apple-darwin --adb-path= --adb-test-dir= --rustcflags "   -O --target=x86_64-apple-darwin" --src-base /Users/kevin/code/rust/src/test/run-pass/ --build-base x86_64-apple-darwin/test/run-pass/ --ratchet-metrics tmp/check-stage2-T-x86_64-apple-darwin-H-x86_64-apple-darwin-rpass-metrics.json --mode run-pass

running 1280 tests
test [run-pass] run-pass/anon-extern-mod.rs ... ok
test [run-pass] run-pass/alias-uninit-value.rs ... ok
test [run-pass] run-pass/alloca-from-derived-tydesc.rs ... ok
test [run-pass] run-pass/anon-trait-static-method.rs ... ok
test [run-pass] run-pass/argument-passing.rs ... ok
test [run-pass] run-pass/alignment-gep-tup-like-1.rs ... ok
test [run-pass] run-pass/anon-extern-mod-cross-crate-2.rs ... ok
task <unnamed> failed at 'assertion failed: `(left == right) && (right == left)` (left: `-1`, right: `0`)', /Users/kevin/code/rust/src/libstd/os.rs:400
task <unnamed> failed at 'assertion failed: `(left == right) && (right == left)` (left: `-1`, right: `0`)', /Users/kevin/code/rust/src/libstd/os.rs:400
Abort trap: 6

The code failing seems to be here in os.rs:

#[cfg(unix)]
pub fn pipe() -> Pipe {
    unsafe {
        let mut fds = Pipe {input: 0 as c_int,
                            out: 0 as c_int };
        assert_eq!(libc::pipe(&mut fds.input), (0 as c_int));
        return Pipe {input: fds.input, out: fds.out};
    }
}

It looks like pipe is failing here for some reason.

[alexcrichton]

Can you try running make check with RUST_THREADS=1? It's a known problem that on OSX we create too many file descriptors in the test suite and right now this just isn't properly handling the errors. I thought there was an open issue, but I couldn't seem to find it...

[pnkfelix]

Yeah I've been running into this too. The standard workaround is to increase the limit on the number of file descriptors, but I would prefer to put in a solution that didn't require that.

Issue #7772 is most likely the issue that @alexcrichton was thinking of. (Its closed, but I'm not quite clear on whether it was closed because the bots had their file limits increased, or if the increase in the limits is masking the fact that this bug persists.)_

[pnkfelix]

(Also, I've been thinking it would be nice to change the os.rs code here to raise conditions rather than assert_eq'ing that the call always succeeds. Not that this would fix the problem, but it would allow people to actually write more robust code. Maybe I'll open an issue for that.)

[alexcrichton]

Ah yes, that was indeed the issue I was thinking of. It appears that the libstd tests automatically increase the file descriptor limit, but this is just affecting compiletest now because it's got so many children.

I think the fix here is to call raise_fd_limit in compiletest on osx. Doing it in a non-hacky way could get interesting though.

[ashee]

Here's how I raised the limits based on http://superuser.com/questions/302754/increase-the-maximum-number-of-open-file-descriptors-in-snow-leopard

echo 'kern.maxfiles=20480' | sudo tee -a /etc/sysctl.conf
echo -e 'limit maxfiles 8192 20480\nlimit maxproc 1000 2000' | sudo tee -a /etc/launchd.conf
echo 'ulimit -n 4096' | sudo tee -a /etc/profile

I had to reboot for the settings to take effect.

[andrew-d]

Also see the section in the wiki.