1230790 - SIGINT not passed to win32 programs when executed via msys bash

Status: RESOLVED DUPLICATE of bug 1725895

(Firefox Build System :: MozillaBuild, task)

Description

[Gregory Szorc [:gps]]

There is a longstanding issue where msys bash does its own signal handling, preempting signal handlers in invoked processes from doing sane things. See http://stackoverflow.com/questions/7085492/preventing-msys-bash-from-killing-processes-that-trap-c/7331240.

A workaround is to run `trap '' SIGINT` from bash to have bash ignore the SIGINT, which will result in bash.exe not interfering with signal handling.

Among other things, this impacts every Python process in MozillaBuild, including hg. For hg, if you ctrl-c during a `hg pull`, the transaction will not be rolled back and future `hg` invocations will complain about an abandoned transaction and the user will need to run `hg recover` to recover. If someone ctrl-c's during `hg qpop`, even worse things could occur. It's pretty nasty behavior.

The SO question contains an interesting hack to set the console mode of applications with ENABLED_PROCESSED_INPUT so ctrl-c is handled as stdin input and not a signal. Of course, every win32 application would need to implement such a thing.

I'm, uh, not sure what we want to do about this. Apparently MinTTY restores sane behavior, although I haven't verified.

Comment 1

[Dave Townsend [:mossop]]

FWIW using `trap '' SIGINT` made it impossible to kill a heroku process I ran.

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

We probably should add the workaround to MozillaBuild by default, because spending 20mins for meaningless recovery on hg repo is much more expensive than opening task manager and kill a process that you wanted to kill with ctrl-c but failed because of this hack.

Comment 3

[Dave Townsend [:mossop]]

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #2)
> We probably should add the workaround to MozillaBuild by default, because
> spending 20mins for meaningless recovery on hg repo is much more expensive
> than opening task manager and kill a process that you wanted to kill with
> ctrl-c but failed because of this hack.

Note that when I said impossible to kill, I meant I had to restart my computer to kill it. The task manager wouldn't do the job.

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

Why wouldn't task manager do the job? I don't understand... What happens to that process? Can you instead use "kill -INT <pid>" if you are currently able to kill it via Ctrl-C?

Comment 5

[Dave Townsend [:mossop]]

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #4)
> Why wouldn't task manager do the job? I don't understand... What happens to
> that process? Can you instead use "kill -INT <pid>" if you are currently
> able to kill it via Ctrl-C?

The process just didn't go away. I can't retest anymore as I don't use heroku now.

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

Sounds like it isn't a problem itself anymore :)

Comment 7

[Dave Townsend [:mossop]]

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #6)
> Sounds like it isn't a problem itself anymore :)

Given the plans to switch to WSL hopefully this won't be an issue we need to fix at all anyway.

Comment 8

[Xidorn Quan [:xidorn] UTC+10]

But we are still using MozillaBuild at this moment... so it may still be worth fixing if we are going to release a new version of MozillaBuild, e.g. for bug 1383578.

Comment 9

[Mitchell Hentges [:mhentges] 🦀]

I'm optimistic that the last five years of improvements to msys-core and mintty will have this no longer be an issue once we embrace MSYS2.