Ctrl-C on rebase leaves behind a stale index.lock file

[orgads]

It happens to me frequently that in the middle of a rebase I cancel it using Ctrl-C, and then it leaves a stale index.lock, which must be removed manually.

IIRC I had it with other operations as well, but I can't tell for sure.

[orgads]

Any news? This happens to me quite frequently...

[dscho]

Any news? This happens to me quite frequently...

I guess I do not cancel rebases, so the bug does not affect me...

To be honest, I have no idea what is really going on. I know what should be going on: Inside MinTTY, an MSys2 Bash is running. From this Bash, you call a shell script, which is handled by the same Bash via forking a new MSys2 process. This process in turn wants to fork a new process for every external executable called by the script, e.g. git.exe. Now, git.exe is not an MSys2 process, so it has no idea about signal handling or other POSIX niceties. Therefore, a POSIX wrapper process is started that in turn runs git.exe and tries to handle signals for it, e.g. accepting a SIGTERM and killing the process.

And here is where things went wrong in my tests earlier this year: git.exe would be killed, but none of its child processes. One symptom of this behavior was that quitting the pager of git log would not stop the git-log.exe process at all.

To remedy this, I implemented this patch series that makes sure that children of non-MSys2 processes are killed when a SIGTERM was received.

My guess is that we would need to do something different there, such as sending a different kind of "signal" via TerminateProcess() to give Git a chance to run its signal handler to remove the temporary files.

Hopefully this provides you with enough information to go further.

[dscho]

To be clear: I have unfortunately no time to spend on this ticket in the foreseeable future.

[dscho]

@orgads would you have time to drive this issue a bit? I think that I know what is going on, but I am too short on time to investigate.

[sxlijin]

I can't reproduce it; am on Win7 x64:

git version 2.10.1.windows.1
sizeof-long: 4
machine: x86_64

[dscho]

@orgads this has been tough to fix, and it would not have happened without @whoisj's excellent guidance. The newest snapshot should fix this issue. Please test.

[orgads]

Looks good. Thanks!