Closed Bug 1230790 Opened 9 years ago Closed 3 years ago

SIGINT not passed to win32 programs when executed via msys bash

Categories

(Firefox Build System :: MozillaBuild, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1725895

People

(Reporter: gps, Unassigned)

Details

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.
FWIW using `trap '' SIGINT` made it impossible to kill a heroku process I ran.
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.
(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.
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?
(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.
Sounds like it isn't a problem itself anymore :)
(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.
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.

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.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Product: mozilla.org → Firefox Build System
You need to log in before you can comment on or make changes to this bug.