cargo commands are exiting prematurely (under Emacs `M-x shell`)

[pnkfelix]

Update: This bug is occurring on Mac OS X in a particular (perhaps broken) terminal setup. Still I would like to know why cargo is not behaving properly.

I'm not sure if this is something wrong with my particular setup, or if something has recently changed in Rust or Cargo that would cause this, but I am finding that my cargo invocations (both valid commands and erroneous ones) are exiting prematurely; it seems like the main thread finishes and exits the process, without e.g. flushing buffered I/O. This makes for a frustrating user experience if you don't suspect it is happening.

Concrete examples (where the cases that I pipe the output of cargo to cat cause it to actually finish the desired command, AFAICT).

% pwd
/Users/fklock/Dev/Rust/tango
% ls
Cargo.lock  Cargo.toml~ LICENSE-MIT src
Cargo.toml  LICENSE-APACHE  README.md   tests
% cargo --version
% cargo --version | cat
cargo 0.9.0-nightly (6ffd134 2016-01-26)
% cargo build
% echo $?
101
% cargo build | cat
   Compiling winapi-build v0.1.1
   Compiling libc v0.2.6
   Compiling kernel32-sys v0.2.1
   Compiling walkdir v0.1.5
   Compiling filetime v0.1.9
   Compiling tango v0.3.3 (file:///Users/fklock/Dev/Rust/tango)
% echo $?
0
% 

[pnkfelix]

Note in particular this sequence of operations:

% cargo --version
% cargo --version | cat
cargo 0.9.0-nightly (6ffd134 2016-01-26)

That should definitely not be happening, right?

[pnkfelix]

actually, I think this is something wrong with the particular terminal under which I was running cargo... i.e. when I opened a fresh terminal, the problem seemed to go away in the new terminal.

Still, commands like ls are working properly, so what's up...?

[pnkfelix]

here is a gist of dtruss instrumenting the cargo run when its output is not piped to cat ... (its the best thing I can think of to get concrete information about what is happening underneath the hood here...)

https://gist.github.com/pnkfelix/70905ba23cdda7213819

[pnkfelix]

I was able to open up a fresh Emacs instance (with --no-init), run M-x shell, and I still see the same bad behavior from cargo build.

I used to be able to run cargo no problem from underneath M-x shell, so I am guessing something has changed, but I still don't know if its due to something in the Rust std lib or if it is due to cargo.

I'll try to at least bisect over the multirust nightly distributions.

[pnkfelix]

Okay bisection over the nightly builds gives us some more data on where this may have been injected:

% /Users/fklock/.multirust/toolchains/nightly-2016-01-01/bin/cargo --version
cargo 0.8.0-nightly (08da2f5 2015-12-21)
% /Users/fklock/.multirust/toolchains/nightly-2016-01-25/bin/cargo --version
cargo 0.9.0-nightly (f052d99 2016-01-24)
% /Users/fklock/.multirust/toolchains/nightly-2016-01-26/bin/cargo --version
cargo 0.9.0-nightly (f052d99 2016-01-24)
% /Users/fklock/.multirust/toolchains/nightly-2016-01-27/bin/cargo --version
% echo $?
0
% /Users/fklock/.multirust/toolchains/nightly-2016-01-27/bin/cargo --version
% /Users/fklock/.multirust/toolchains/nightly-2016-01-27/bin/cargo --version | cat
cargo 0.9.0-nightly (6ffd134 2016-01-26)
% 

[pnkfelix]

(I have replicated the problem on local cargo builds, so I am now bisecting across the two nearest commits listed above, namely f052d99 and 6ffd134 )

[pnkfelix]

bisection results:

git bisect bad 6ffd134
git bisect good f052d99
git bisect bad c1a5a477e3b7750b413ce0f74d555e9e9dc562ee
git bisect good b24bf7e6a42027b140eb136a336b3444d879658c
git bisect bad 44c0d7b78548c83b6df4935fdbb15be62f30d685
git bisect bad dd34296008c6b1bf6cc1411d92c55d80ebd5c690

Apparently this was injected by dd34296

cc @alexcrichton

(again, it is possible that this is pointing to something wrong at a deeper level within the rust std lib itself.)

[pnkfelix]

I found the problem (or at least its indirect source): it was due to the upgrade of the term crate from version 0.2 to version 0.4.

I will put up a PR for my local changes that reverted the version that cargo uses back to 0.2. I don't really want to invest the time right now into figuring out what has happened to term itself that causes this.

[alexcrichton]

Oh dear this does seem bad, thanks for the investigation @pnkfelix!

cc @Stebalien, you may be interested in these failure?