Ruby executed via /usr/bin/env cannot be interrupted

[orgads]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.17.0.windows.1.26.g82f1b61609
cpu: x86_64
built from commit: 82f1b6160988ab0a61edebef6ed1c3048b66a3a4
sizeof-long: 4

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

ruby --version:

ruby 2.4.4p296 (2018-03-28 revision 63013) [x64-mingw32]

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

/usr/bin/env ruby -e 'sleep 10' # Cannot be interrupted
<Ctrl-C>
ruby -e 'sleep 10' # Can be interrupted
<Ctrl-C>
-e:1:in `sleep': Interrupt
        from -e:1:in `<main>'

• What did you expect to occur after running these commands?

It should stop the process

• What actually happened instead?

It doesn't.

[orgads]

I also had this issue with previous Git versions (at least since 2.16, possibly before). Not sure if this is Ruby's or MSYS's fault.

[dscho]

@orgads I am glad you opened this ticket. I am glad because I know a little bit about you from previous experience, in particular that you are quite capable, once you put yourself behind fixing an issue.

In this case, I would like to suggest to instrument the code in exit_one_process() (and then rebuild and test) to see what the address is in the different switch cases, where it falls through, and what the error conditions are.

Of course, the culprit may very well be that this code (whose intention is to avoid killing MSYS2 processes using the method intended to kill non-MSYS2 processes) does not do what it is supposed to do: https://github.com/git-for-windows/msys2-runtime/blob/fa84a1f06b83b54847e6505df2bdb6db1860f47f/winsup/cygwin/include/cygwin/exit_process.h#L325-L330

[orgads]

Added some debugging info. Patch here: https://gist.github.com/orgads/460270b84d9b0849b26d65ca15bcd302

$ ruby -e 'sleep 5'
exit_process_tree. pid: 8340, signo: 2
match pids[0] == 8340
signo: 2
address: 0x77614B10
injecting: 0. thread_id: 4704, thread: 0x164
-e:1:in `sleep': Interrupt
        from -e:1:in `<main>'
$ env ruby -e 'sleep 5'
exit_process_tree. pid: 10772, signo: 2
match pids[0] == 10772
signo: 2
address: 0x77614B10
injecting: 0. thread_id: 5496, thread: 0xF8
<Not terminated. Another Ctrl-C>
exit_process_tree. pid: 0, signo: 2
match pids[0] == 0
match parent pids[0] == 0
cyg_pid: -1
Added pids[1] = 4
match parent pids[1] == 4
cyg_pid: -1
Added pids[2] = 376
match parent pids[2] == 376
cyg_pid: -1
Added pids[3] = 932
match pids[0] == 0
match pids[1] == 4
match pids[2] == 376
match pids[3] == 932
signo: 2
address: 0x77614B10
injecting: 0. thread_id: 1, thread: 0x0
address on SIGTERM: 0x77702840
injecting: 130. thread_id: 1, thread: 0x0
signo: 2
address: 0x77614B10
injecting: 0. thread_id: 1, thread: 0x0
address on SIGTERM: 0x77702840
injecting: 130. thread_id: 1, thread: 0x0
signo: 2
address: 0x0
address on SIGTERM: 0x0
signo: 2
address: 0x0
address on SIGTERM: 0x0

[orgads]

Some more observations: When running through env, exit_process_tree receives the pid of ruby (as main_process), and not of env. Still, none of them receives the signal.

[dscho]

Probably ruby has env as parent process, and I vaguely seem to remember that there was some code that left SIGINT handling to the process group leader. Maybe this is what is at play here?

clicketyclick

https://github.com/git-for-windows/msys2-runtime/blob/fa84a1f06b83b54847e6505df2bdb6db1860f47f/winsup/cygwin/exceptions.cc#L1147-L1165

But that only happens in the ctrl_c_handler() function which, as far as I can see, is only installed via SetConsoleCtrlHandler() and not called directly.

[dscho]

What is this all about?

[orgads]

Ruby scripts typically use the shebang #!/usr/bin/env ruby, and not being able to interrupt them is, well, unfortunate.

I bisected the msys2-runtime directory in MSYS2-packages, and found that the first bad commit is git-for-windows/MSYS2-packages@ac09de9.

[orgads]

I added some logs in ctrl_c_handler. It is never called for neither of the executions.

[dscho]

I bisected the msys2-runtime directory in MSYS2-packages, and found that the first bad commit is git-for-windows/MSYS2-packages@ac09de9.

Hmm. That one switches to calling GenerateConsoleCtrlEvent()...

I also tried this with a very simple C executable that basically just registers a ConsoleCtrlHandler() and then sleeps for ten seconds.

And while I could send a CTRL_BREAK_EVENT successfully (and it was caught correctly), the CTRL_C_EVENT seems to be simply ignored 😦

[orgads]

Any progress with this? Anything I can do to help?

[dscho]

@orgads glad you asked: git-for-windows/msys2-runtime@master...dscho:ctrl-c-harder

This needs testing, especially in a 32-bit runtime that wants to interrupt 32-bit and 64-bit processes, and it needs to learn to skip processes where IsProcessCritical() returns TRUE (but we have to load that symbol dynamically because it is available only in Windows 8.1 and later).