Long stall when interrupting a long-running compilation with Ctrl+C on MSYS

[hiddenhare]

nightly-x86_64-pc-windows-msvc (default)
rustc 1.47.0-nightly (2d8a3b918 2020-08-26)

mintty 3.3.0 (x86_64-pc-msys)

To reproduce: Open up the default MSYS command line (MinTTY) on Windows 10. Download the ggez/ggez repository, navigate to that repository's root directory, and run cargo run --example 01_super_simple. Wait for the progress bar to reach at least 100/257, and then interrupt compilation by pressing Ctrl+C.

Expected behaviour: Control should return to the command line near-instantaneously. This is the observed behaviour when using cmd.exe.

Observed behaviour: The command line becomes unresponsive for tens of seconds. Throughout this time, Task Manager reports that several instances of rustc.exe are consuming a combined 100% CPU usage. Disk usage and memory usage remain at baseline.

[alexcrichton]

Handling ctrl-c is pretty tricky on Windows. It doesn't work the same way that it does on unix. When you ctrl-c a program at the command line it typically does the equivalent of kill -9 $pid on Unix, meaning the program has no way to clean up after itself. On Windows Cargo uses "job objects" so when Cargo is erroneously torn down it takes down the whole process tree with it. If your cargo.exe in PATH is actually rustup, though, then we also rely on rustup to do that.

Can you try setting CARGO_LOG=cargo::util::job to see if any errors are happening when setting up the job object? There may also be an error on rustup's side but I don'tk now how to debug that.

[ehuss]

FWIW, I was unable to reproduce this. I tried a few different environments and terminals and versions of MinTTY.

Is it specific to building that example (01_super_simple)? Does Ctrl-C need to be pressed while building a specific package? I'm wondering if it is running a build script that is doing something unusual.

Was Rust installed with rustup?

[hiddenhare]

@alexcrichton: If I run CARGO_LOG=cargo::util::job cargo run --example 01_super_simple, and interrupt it with Ctrl+C as described above, nothing unusual is printed to the console.

@ehuss: The problem isn't specific to ggez; it seems to occur for any large, long-running compilation, but only when it has made significant progress. For example, if I start building 01_super_simple and then interrupt it when the progress bar is only at 10/257, the problem doesn't occur.

My environment is an up-to-date MSYS2 installation on Windows 10. I launch the console by selecting the Start Menu item named "MSYS2 MinGW 64-bit". This is a shortcut for the command-line script:

C:\msys64\msys2_shell.cmd -mingw64 -use-full-path

Rust was installed with rustup.

[alexcrichton]

Can you try executing Cargo directly and see if that makes a difference? For example not executing the rustup wrapper named cargo.exe but instead the cargo.exe directly

[hiddenhare]

Interestingly, whereis cargo gives me /c/users/myname/.cargo/bin/cargo.exe, so it looks like I'm might already be bypassing the rustup wrapper?

However, the bug is unchanged when I run any of these commands following a cargo clean:

cargo build --example 01_super_simple
rustup run nightly cargo build --example 01_super_simple
/c/users/myname/.rustup/toolchains/nightly-x86_64-pc-windows-msvc/bin/cargo.exe build --example 01_super_simple

[alexcrichton]

Alas :(

Unfortunately there's not much we can do to help fix this without being able to debug it more, but it's somewhat difficult to know what to debug at this point...